commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject RE: [subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)
Date Mon, 29 Mar 2004 15:07:02 GMT


> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> > Sorry to get into this one late.  Had too though since I'm one of those
> > directory folks :-).
> 
> I'm finally finding that I can get svn installed on suse and os x [it's
> not without issue] and am looking forward to migrating to svn over the
> next year in all my endeavours.

I know you had a few bumps on your way, I'm glad to hear things are 
progressing.

> > Subversion affords us a more liberty.  Besides the obvious renaming and
> > deleting of files and directories without the loss of history etcetera,
> 
> Never really had that much pain doing this on the CVS server. One of the
> pluses CVS had was that the system was easily understandable and if CVS
> did not support a feature, you could often use something like perl to gain
> said feature. CVS hackery was effectively an easy way to extend CVS.
> Lookinjg at the SVN repo, it looks a lot more complicated and will require
> far more in the way of effort to change, ie) writing [I assume] berkely db
> client code.

CVS is really great if you have access to the repository and don't make 
mistakes.  However CVS came together out of necessity as some project 
level meaning was to be given to a set of RCS files.  Basically it's a 
kludge although not a bad one.  Subversion is a complete rewrite and 
has some subtle yet major differences.  However I do feel safer knowing 
that there is less 'hackery' now while preserving the ability to extend 
subversion.  

In the past, I made a living off of other people's ignorance when it came 
to administering CVS and hacking around its flaws.  Don't get me wrong 
I'm glad to have profited but would rather have worked on creating 
something new rather than working around a flawed piece of software.  
Rather than spend time knowing the internals of a VCS to make up for 
its shortcomings, I'd rather put that time towards using it to its 
fullest extent and improve the development lifecycle.

<snip/>

> > things along the way.  Plus the ease of branching by just copying
> > directories and merging them makes large re-factoring efforts without
> > disrupting development a breeze.  These features have for these reasons
> 
> Branching and tagging in svn confuse me. People talk about them being
> easier, but the difficulty of such things in CVS is not the action, but
> the management of multiple branches of code. All i see in SVN so far is a
> different way [which may be faster on the server, but who cares unless

Yes svn could be difficult because it requires breaking old CVS habits.  The
fact that a revision# = tag# in subversion may confuse the need for branches
in the traditional CVS sense.  Branching just becomes a very efficient copy
operation.  IMHO this is an improvement.

> there are lots of binary files] and not an improved way. Is there any
> concept of live vs dead branches? Any way to implement naming conventions?
> R/W setting of branches?

Subversion like all good systems leaves the interpretation (meaning) of the
state of a branch up to you but gives you the tools you need to manage it.
The tools here are user definable attributes.  So when you want to devise a
scheme for tracking the state of your branch you have first class support
from subversion to do so.  CVS never gave you this although you could mimic
it with workarounds.

> Also, branches seem to have less in the way of support as you now have to
> come up with your own filing hierarchy to contain them. While the new SVN
> structure seems simpler, which might lead to a more easily implemented
> powerful system, there's nothing to crow about yet.

You're right that it will take time before the entire community begins to
see the true value of svn.  

> > Going back to CVS is not an option for me after tasting development
> > using subversion: it would mean going backwards.  The best description
> > I can give of the having to use CVS after using subversion is when I
> > have to use dial up rather than high speed internet access.  It's just
> > frustrating.
> 
> Your anology reminds me of something that frustrated me. Subversion
> apparantly has a different commit method, it sends patches up and not full
> files [?]. This makes for less bandwidth usage. Anyways, the bit that
> frustrates me is the SVN seems unable to work with basic WebDAV clients,
> which I think quite a few of us assumed when it talked about using WebDAV
> [yeah, I don't grokk DAV]. Anyway, this means that I can't mount a
> subversion repo as a virtual drive and commit by simply copying a new
> version of a file in, or editing it, and I can't use a tool like
> Dreamweaver to change it. It does work in a read-only way though, just
> errors on commits.

Yeah I was a little disappointed by not having these features you mention
also.  I think they are due to only a partial implementation of DeltaV but
others would know about this better thank I.  Regardless it would be sweet
to have the write half also because then everything is a standard wrt the
comm. protocol portion of svn.

> > Subversion is the future that fits the latest paradigms in software
> > development.  I cannot stress the importance of the positive effects
> > it will have for development here at the ASF not to mention for
> > infrastructure.  And ultimately the transition will have to happen
> > at some point.
> 
> From what I understand, SVN is written by the maintainers of CVS? Which
> implies that CVS is dead and SVN is basically a very non-backwards
> compatible CVS-2. That's the main reason to move for me.

That's also another reason as well.  I only think of SVN as a CVS
replacement about 40% of the time now.  It might have been greater when I
started working with it and said 'Oh it has all the cvs commands I used
before'.  Then as you begin to play and experiment with its features you
realize this road starts where CVS left off but can take you far far away.

Also the assignment of global repository version numbers for each change is
truly awesome.  I really don't need to tag anything anymore.  CVS assigns a
revision per file with tags to track them.  SVN uses a global repository
version number for changes.  This IMO is the biggest difference and is a
paradigm shift in the way a repository is thought of in the user's mind.  It
makes SVN much more than CVS-2.  Also a single unique version number for an
entire change transaction makes it really easy to reference fixes in JIRA or
any other issue tracking tool.  

> So far, the only improvements I've found are the ability to move files, a
> slightly nicer set of messages when committing and 'svn status' replacing
> 'cvs -nq update'. A lot of it feels more generic, which can be a good
> thing.
> 
> > BTW in the past I have been a CVS consult and lived and swore by it
> > since it put food on the table.  I cannot overstate how emphatic
> > I have been regarding CVS.  It was a religion for me.  Now after years
> > of using CVS, I swear by subversion and that's got to be worth
> > something when said by a CVS diehard.
> 
> I suspect complaints like "but it's too complicated", "it's not well
> supported" etc were heard by RCS die-hards when CVS came out too :)

Yeah support is less than what there is for CVS but in time this will
change.  It will change very rapidly too.  I think SVN fixes all of the
complaints users have had with CVS and for that reason it will be adopted
much more readily by people who had avoided CVS for those reasons.  In the
end, SVN should have a bigger following with much more support.  You
obviously already see that.

> I expect to not be using CVS in a year [home,apache,osjava,work], but it's
> going to take a good chunk of time to transform my cvs-admin knowledge
> over to svn.

Great then we can help each other along as we learn the ins and outs of
subversion.  I'm sure we'll be finding ways to use SVN in ways the authors
never conceived.  I'd like to hear the experiences of others as they too
make the move to SVN, learn how to use it and extend it in novel ways.

Alex





---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message