Re: [Pyobjc-dev] CVS Sucks.

[b.bum <bb...@ma...>]

On Apr 8, 2004, at 3:01 PM, Pierce T.Wetter III wrote:
>> Anyone want to move to Subversion?
>>
>> I can have the project converted, moved over and setup in short order 
>> -- potentially even preserving all history information.  It mostly a 
>> matter of grabbing a block of time where the CVS repository doesn't 
>> change.
>>
>> A number of advantages:
>>
>> 	- it isn't CVS
>
>      Not being CVS isn't an advantage in and of itself. That only 
> works in presidential elections.

Not true.   CVS is broken by design in a couple of areas that 
Subversion is specifically designed to not be broken.

	- horrible conflict resolution support
	- no atomic commits
	- broken handling of binary files
	- tagging/branching is broken;  subversion is not

>> 	- web based repos browser that is much more straightforward
>
>    But no Cocoa GUI tool like CVL.

Scplugin works fine.   So does svnX (or whatever it is called).   
Neither is currently as refined as CVL, though scplugin is close and is 
integrated into the Finder, which is really quite convenient.

>> 	- can mount the repos in Finder and drag a copy of the trunk or 
>> branch just like any other filesystem
>
>    If you're not on dialup. And only if the repository is hosted on a 
> WebDAV server.

And if you are on dialup, then Subversion can support a boatload of 
operations -- reverts and diffs -- without making a roundtrip to the 
server.

>> 	- repository checkout -- anonymous or otherwise -- is considerably 
>> more straightforward
>
>   It's what two steps to checkout?

A subversion checkout can be documented as a single URL.   CVS cannot.  
That is a big difference.

>> 	- no more "wait 24 hours or so before changes are visible in 
>> anonymous repos"
>
>   That's a SF thing, not a CVS thing though.

We are currently SF repository and, therefore, this "feature" of SF is 
a feature of using CVS unless we were to decide to go elsewhere.

>> 	- much better tagging/branching
>
>   Well, better tagging. I'm not convinced the branching is better.
>
>> 	- atomic commits
>
>   Does PyObjC ever run into this as a problem.

Yes.  I-- and others-- have frequently made changes to and committed 
across some combination of the Modules, Library, tests, Examples, and 
Documentation.  With CVS, there is NO WAY to know that you have 
identified every single file that was touched by a commit.   With SVN, 
it is trivial to do so.   This also plays well into bug tracking and 
other casual project management methodologies -- changes #1234 and 
#1238 were to fix bug #5595.    Not possible with CVS.

>> Disadvantage:
>> 	- it is a change, and change is scary
>
>      svn has some disadvantages too.
>
> I like Gnu arch better, especially for open source projects.
>
> http://wiki.gnuarch.org/

Interesting, but I don't find it compelling -- with 100+ sub-commands, 
it seems a bit overly complex (hard to learn).  It also doesn't "feel" 
like arch was designed to be usable by anyone but hardcore software 
developers.

(Personally, the GPL is a deal killer-- but that is just me)

And, of course, no GUI tool for arch/tla, either (though scplugin could 
be bent to work with it, I'm sure).

> SVN is definitely a solution to source control, but I'm not convinced 
> its better then CVS.
>
>   1. Its slower on dialup then CVS in my experience.

Haven't encountered that, but I could definitely see how the lack of 
gzip --best on the transport layer would suck.

Are you working with a Subversion repository for which mod_compress is 
enabled?

>   2. Tagging is better, branching looks better until you try to use 
> it, then you realize that they forgot merging, which is the hard part 
> of branching. So it ends up just being "different".

Haven't encountered that problem and I have heard a lot of praise from 
people that are managing really huge source trees with Subversion 
(Linux distributions, in particular).

Personally, I have found that the combination of atomic comments and 
the use of the repository revision numbers to be such that merges are 
much easier to deal w/in Subversion than CVS.

http://svnbook.red-bean.com/svnbook/ch04s03.html

>   3. The repository is opaque.

Agreed.

>  While SVN seems to be better designed then CVS, that's not saying 
> much. Its not clear that it adds enough to CVS to be worth the trouble 
> to switch.

Does for me.  Loads better.   I have been using CVS for a long time and 
Subversion is a huge relief.

b.bum