commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)
Date Sun, 28 Mar 2004 18:19:38 GMT


On Sat, 27 Mar 2004, Alex Karasulu wrote:

> Hi,
>
> 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.

Some questions on the below though:

> Subversion for eXtreme Refactoring
> ==================================
>
> 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.

> we find that our development style can be geared towards XP.  These
> features are changing our outlook.  We are no longer worried about
> chewing up a repository to re-factor on a whim.  I personally have
> re-factored conservatively on CVS because there was no way to easy
> way to cleanup the consequences afterwards: loss of history and empty
> directories.  But now there are no inhibitions with subversion so we're
> free to be liberal with re-factoring - it's the way we code.  Bang
> something rough out and then gradually reshape it as we discover new
> 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
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?

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.

> 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.

> 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.

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 :)

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.

Hen


---------------------------------------------------------------------
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