Re: [Lcd4linux-devel] LCD4Linux CVS=>SVN

[Martin H. <ma...@he...>]

Hi Maxime/Sam,

> One of the advantages of Free Software is that you have to choice of
> the tools you want to use. Some projects choose CVS, others Arch,
> others Subversion, ... It's a diversity we have to live with, and it's
> far from being a harm.
I'm not saying that diversity is harmful - but when one has a limited 
amount of time to work on stuff like lcd4linux, one needs to chose what 
one spends one's time on - and I'd rather work on code (or even 
documentation) than learn a new tool, just because it's deemed superior 
to the one I already know how to use. Now, if there's a specific feature 
in the new tool that I need/would benefit from, of course a switch makes 
sense. And if Michael feels he would benefit from switching to svn, I 
guess he should.

Also, remember that I didn't tell Michael he shouldn't switch - I just 
expressed my point of view that if lcd4linux was switching to a 
different tool to manage the code, I would no longer be able to 
participate in development (and I even pointed out that I haven't done 
so in the recent past anyway, so the effect on the project would be none).

> When I'm on the 'user side', I don't see much difference between 'svn
> up' and 'cvs up'.
Well, I guess both cvs and svn offer more than just the "update" command 
and I'd be extremely surprised if switching to svn on the client side 
would be as simple as replacing "cvs" in each call with "svn". Having 
briefly glanced over the svn manual, I find that pretty much every 
command beyond update/add/commit is (even if only slightly) different, 
and that features like branching/merging are _rather_ different. Let 
alone workspace administration, but I agree with you that this is not 
part of the "user side" (it can be for CVS, but only because one is 
working around a limitation of CVS).

Anyhow, if there are subtle differences, that's the most dangerous part 
to me. I want to avoid trashing a project at work by using svn commands 
instead of cvs commands (or vice versa). If I could switch _everything_ 
I work on to svn, I probably would (even though I'd also look at 
monotone or arch first, since I'd also like the possibility of some sort 
of "replication" between local and remote repositories).

> Svn is nice. I've been using it since it have been declared stable by
> it's developpers (~ 18 months ago), and I can tell you that the two
> features you are pointing out are not the ones I'd choose to show
> Subversion superiority on CVS. 
I think you misunderstood me. To me, CVS does the job I need it to do. 
It has some quirks that are annoying at times (quirks that svn doesn't 
have) but the quirks are not bad enough to justify switching to svn (to 
me - I'm aware that other people have other preferences).
Wether I'm using the most superior product available doesn't really 
matter to me, as long as the tool I'm using gets the job done.

Maybe I wasn't really clear with what I was trying to say in my mail - I 
have nothing against subversion. I've heard lots of good things about 
it. It can do a lot that CVS can't do, and it does some things better 
than CVS.  But I know CVS, and with it I can do what I need to do. I 
don't have the spare time to learn every tool that comes up and is 
better than the tools I already use.

> Of course, handling of binary files is
> important, but in my opinion, moving and copying files or entire
> directories without loosing the history (svn mv, svn cp) is even more
> important. 
Depends on one's point of view/needs, I guess. Maybe I'm just too used 
to CVS by now - since to me, doing a rename of a file as a remove and 
subsequent add is not a problem. Indeed, to CVS there is no connection 
between the old file and the new one (which is what I assume you're 
referring to with "loosing the history"), but I haven't come across an 
instance yet where that was a problem. I agree that subversions way of 
handling that is much better than the approach of CVS.

>>But if you decide to switch, you may also want to take a look at the
>>latest news from sourceforge - from what I've heard, they're working
>>on offering svn.
> 
> 
> IIRC, LCD4Linux left Sourceforge because of it's poor reliability ...
The webservers are definately unreliable at the moment (and have been 
for quite a while) - but I'm not aware of any major issues with the 
cvs-servers (other than that the backup servers, which are used for 
anonymous access, always take a couple of ours to sync).
And again, I didn't tell Michael he shouldn't use bulix.org svn servers 
(I assume they're yours) - I just told him that he "may also want to 
check out" the new developments on SF.

Martin