info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: To get some information regarding CVS


From: Arthur Barrett
Subject: RE: To get some information regarding CVS
Date: Sun, 28 Sep 2008 18:28:42 +1000

Michael,

> for the filewise "expand" keyword, and also adds the 
> revisionwise "kopt"
> keyword.  If the meanings of these values is documented somewhere, a
> pointer would be much appreciated.  The CVSNT manual link 

http://www.cvsnt.org/manual/html/Substitution-modes.html

The keywords themselves can be used defined - so this list is arbitrary.
http://www.cvsnt.org/manual/html/Keyword-substitution.html
And
http://www.cvsnt.org/manual/html/User-Defined-Keywords.html

> that you sent
> me has a little bit of user-level information about the "binary"
> options, but I couldn't find information at the level of detail that I
> would need.

If you need more detail than what is shown in the above links you'll
have to ask for it explicitly on the CVSNT newsgroup - but all the
information I can think of that you'd need is there.

> By the way, we use the same rcsparse infrastructure as used by ViewVC,
> so the CVSNT project itself would directly benefit the 
> ability of third
> party tools to understand your repository format.

I know that many users of CVSNT do use ViewVC and that Bo Berglund spent
quite a lot of time on both projects - I'm surprised it's not already
there - if it's not then the patches Bo made probably were never
accepted, and I'd not be interested in duplicating his effort.


> filename -- I don't know what this is, so I can't guess 
> whether it would
> be interesting for cvs2svn.

The filename - err, name of the file?  Since CVSNT supports rename the
name of the RCS file is not necessarily the name of each revision of the
file.

> bugid -- presumably allows a connection to a bug database; at most we
> might consider migrating the information to a tag in the output
> repository for the use of other user tools.

That wouldn't work which is why we have bug id's - a single bug id can
appear on many revisions.  Then when you need to merge a bug the server
can collect all of the revisions that are relavent - bugs are rarely
fixed in a single commit.  As far as I know SVN has not equivalent.

> permissions -- from the name of it, this is probably not interesting
> right now, since we don't try to migrate permission 
> information to SVN.

Again no SVN equivalent.

> > And I'm in the process of adding 'username' (for where the 
> username is
> > different to the author - don't ask why - it's a corner 
> case that needs
> > to be covered).
> 
> I'm afraid I'm going to ask why anyway :-)  Is it like the difference
> between "author" and "committer" in git?  cvs2svn can commit to git,
> too, so this metadata might also be useful.

I guess so - do you have a link that explains the difference in Git?

> >> If anybody wants to add CVSNT support to
> >> cvs2svn/cvs2git, I would be happy to help them.
> > 
> > I think the main reason why noone is contributing this 
> effort is that
> > people are more interested in moving from SVN and CVS to CVSNT since
> > [...blah...blah...]
> 
> Yeah.  Right. :-)
> 

Well no - this is a serious issue for anyone whose jobs are about CM or
that support FOSS software use in the enterprise.  I'll break it into
roughly 3 categories:
1) unnecessary duplication of effort (in open source projects)
2) wasted money by organisations who use the software leading to
disenfranchisement with the OSS model
3) a lack of education on CM and the 'real' benefits/purpose of it

Point (1) is a minor philosophical point that has already been
documented and acknowledged the world over that due to egos in the FOSS
comunities that there is far too much duplication of effort.  Whilst
having choice is a good thing - I've not seen a single feature in SVN
that is not delivered better and years in advance in CVS or CVSNT.   The
couple of things that SVN does marginally better (eg: fast tagging -
'logical' human user interface to express branches) could have been done
in a fraction of the time and effort on the CVS or CVSNT source code.
Now the CVS project has made it clear over the years that they don't
want 'feature bloat' so it makes sense that there is at least one
alternative.  

Point (2) has been best documented by a University in France and
summarised in a great article on the valuation of IT assets published in
The Financial Times UK Edition 36,501 on Monday October 1 2007.  In
short the cost of migrating from CVS or CVSNT to SVN is huge, and as I
already indicated above is not based on any benefit the organisation
will see.  This is bad for FOSS since it will be seen as a contributing
factor - when an organisation stipulates ClearCase they get universal
subscription and it never changes over decades - much better for
business.

Point (3) comes back to what I originally wrote - CM has a purpose in an
organisation and no Software CM /VC tool should be employed until it
demonstrates a benefit towards that purpose.  Generally I find the
business driver for CM in an organisation to be either: a need to manage
(customer initiated) changes (patch / bug etc), developer productivity,
security/control/legislation.  In none of these areas does SVN
contribute anything that CVS does not supply (there is no
user-defined-change-sets unless you also have the collabnet tools, there
is no clear productivity gains, there is not security (no failsafe
audit, no file/branch level access control unless you also purchase the
collabnet tools).

With the EVSCM project we've create a Version Control/CM API (library
thingy) that can in theory be used to build many different CM systems,
and an open source implementation with audit, user-defined-change-sets
and secutiry (ie: identical to the current CVSNT but built on the
generic API) and we are also building a commercial implementation that
provides a process/workflow, a nice web interface and support for Web
Folders, CVS/CVSNT, SVN and TeamSystem clients.  But there is no way
that I'd personally encourage anyone to migrate unless they have
documented the costs and investigated the benefits.

Having choice is a good thing - and the svn migrate utility a good one -
and I am happy to supply whatever information is needed to make it work
with CVSNT - because I see openness as important.  There are also bigger
issues at stake that I think should not be dismissed.  Would you
consider putting some warning on the user interface for cvs2svn?  If I
had my way it's be "you are about to perform an action that is
completely unnecessary and likely to cost you a lot of time and money -
are you sure you want to migrate to a system that has no feature that
CVS doesn't already have?  We recommend a cost/benefit analysis and a
clear definition of the business (bottom line) benefit to your
organisation before you continue.  Walk away now while you still can.",
but I'm sure you could come up with something a little more moderate ;)

Regards,


Arthur Barrett








reply via email to

[Prev in Thread] Current Thread [Next in Thread]