[PD-dev] time for svn?
Hans-Christoph Steiner
hans at eds.org
Mon Feb 27 01:53:51 CET 2006
On Feb 26, 2006, at 6:29 AM, David Plans Casal wrote:
>
> On 26 Feb 2006, at 09:51, Frank Barknecht wrote:
>>
>>> Oh, and the tag called "HEAD" in CVS is
>>> usually a directory called "trunk" in SVN.
>>
>> Let me rephrase this a bit, because it's not correct the way I said
>> it: When considering HEAD as a revision, then of course svn also
>> has a
>> current, HEAD revision. What I actually meant to say was that the
>> MAIN
>> branch of CVS usually is a "trunk" directory (or many of them) in
>> SVN.
>
> It's probably worth noting that there is a very good 'SVN for CVS
> users' chapter in the red bean book, here:
>
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.forcvs
Thanks, that's a good start.
But I must say, there is an arrogance to the documentation which I
find distasteful. I'd like to see the "advantages and disadvantages"
section, rather than "forget all you know, because SVN is so much
better". That's a dangerous attitude, every system has
disadvantages, and the developers should be aware of them.
For example, I am sure there are disadvantages to having per-commit
versions rather than per-file like CVS. I'd like to hear the
discussion rather than having someone tell me "forget the other way,
this way is better". Here's a good paper comparing CVS and SVN:
http://www.jini.org/docs/cvs_vs_subversion.pdf
Here's something from the GNU Arch wiki:
http://wiki.gnuarch.org/SubVersionAndCvsComparison
Here's a discussion from the gcc dev list about their switch:
http://gcc.gnu.org/ml/gcc/2005-10/msg00528.html
I think they spell it out, basically branching and merging is better
in SVN, the rest is largely the same in terms of efficiency. I think
we should be doing more branching and merging, so its sounds like SVN
is the way. I just want to make sure what we are getting into.
.hc
________________________________________________________________________
____
¡El pueblo unido jamás será vencido!
More information about the Pd-dev
mailing list