cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)

[Arkadiusz Miskiewicz]

On Friday 09 of September 2005 22:48, Tomasz Pala wrote:

> The difference is this scripts gets a dozen of files in a dozen
> requests and one has to do 2 cvs ups.
> A future script will get 10k specs with 10k svn requests, and how
> many updates would require? (see p. 3)
Do you know that here you are not talking about cvs vs svn but about how we 
want to organise repository layout?

> Let's make a list of COMMON tasks (excluding trivial ones), appropriate
> command sets and compare it.
>
> 1. building a package from given branch:
> cvs:	./builder -bb -R foo bar or ./builder -g and rpmbuild -bb
> svn:	!? rpm uses SPECS/SOURCES subdirs, how the hell this will work
> 	with subdir-per-packet? Another messing script?
svn co .../packages/gcc/trunk somewhere
mkdir somewhere/BUILD...
rpmbuild -bb --define _topdir somewhere

because you would have /packages/gcc/trunk/{SPECS,SOURCES} 

Note that you are comparing quite ugly, huge and hardly maintainable builder 
script (1787 lines) with svn. Now please do that with cvs client only without 
additional stuff.

> 2. updating all resources I've checked out (having CVS/Entries.Static):
> cvs:	cd SPECS, cvs up; cd ../SOURCES; cvs up
> svn:	!?
Exactly the same if you use the same layout as cvs. But the point is to split 
SPECS/SOURCES to nicer scheme and we should talk about that scheme. With new, 
proposed scheme that would need some script to find out checked dirs and svn 
up there. Well exactly the same as in cvs but we would have more dirs then.

> 3. fetching all specs:
> cvs:	cvs up
> svn:
> for pkg in `svn ls http://.../packages/`; do
>         do whatever you need
> done
>
> ohhh, it really sucks...
Again, you seem to think svn == /packages/something layout. These are two 
separate things. With the /packages you get some things and also loose some 
things.

> 4. commiting changes:
> cvs:	cvs ci foo.spec; cd ../SOURCES; cvs ci *
> svn:	svn ci foo
>
> hmmm, not so big difference, don't talk about atomic commits anymore.
> Anyway - if we want this functionality, we could move SOURCES and SPECS
> into higher level repo directory, so that they would be subdirs.
Atomic is the key here. You are trying to ignore that which is weird.

>
> And now NOT COMMON ones:
>
> 5. reverting a commit:
> cvs:	cvs up -r X foo; mv foo{,.tmp}; cvs up -A foo; mv -f foo{.tmp,}; cvs
> ci foo svn:	svn revert foo
>
> no difference for me. Not an argument.
You are talking about _single_ file. Try to revert whioe logical commit of for 
example update of gcc from 4.0 to 4.0.1. It's single command with svn and 
tens with cvs. Reverting one file is as easy in cvs as in svn. Well, in svn 
you can revert some change without checkouting it.

svn merge -rnew:old http://

>
> 5. renaming
> cvs:	manually
> svn:	svn rename
>
> well, I don't care about names, I asked to do this once or twice.
You seem to do not care about a lot of important things. I remember complaints 
from developers that files where copied by cvsadmin not as fast as developers 
wanted.

> 6. access to deleted TAGS
> cvs:	none
> svn:	is
>
> who needs it anyway (OK, you need this in DEVEL example, I don't)
There is HEAD and AC-branch on some package (multiple files). You do merge to 
head and then delete ac-branch. Few days later you want to revert that and... 
huston we have a problem. Mainly because of no atomic commits so you need to 
find out rel for each file and revert it and ... you need to do some guesses 
here. Which branch, which rev, which dates.

7. work on branches
cvs: problematic if you want to work on several branches of the same files 
(quite common for me, head + ac-branch); can be somehow workarounded by using 
builder-like script
svn: easy, separate dirs, can view diffs easily and nicely doing merges with 
for example kdiff3

8. writting scripts for scm like builder
cvs: problematic, parsing everything as strings
svn: great python bindings  (for example I have repo where there is 
pre-commit-hook which checks if to-be-commited php files have correct syntax 
and fails otherwise... very nice)

9. doing diffs
cvs: problematic if you want to compare whole packages, easy for individual 
files but only locally
svn: see how creating diff between release and branch of kdebase package is:
svn diff svn://anonsvn.kde.org/home/kde/tags/KDE/3.4.2/kdebase \ 
svn://anonsvn.kde.org/home/kde/branches/KDE/3.4/kdebase \
> kdebase-branch.diff
_without_ having anything beside svn client locally

We never done this in cvs pld because it was impossible and was very desired 
several times when doing merges between branches.

10. with svk on top of subversion you can work disconnected. never needed it 
(it could be useful for people who travel frequently)

The point here is to get nicer and easier setup to work with not just to 
switch to subversion (or something else). We should think about new 
repository layout, think about benefits and disadvantages. Also any switch 
won't ,,just happen''. It has to be carefuly planed first. Then whole builder 
automatic, builder script and all stuff needs to be ported/written for new 
scm and new repo layout. Demo/test version would need to be set up first etc.

Please think about what could be done better.
-- 
Arkadiusz Miśkiewicz                    PLD/Linux Team
http://www.t17.ds.pwr.wroc.pl/~misiek/  http://ftp.pld-linux.org/