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

[Tomasz Pala]

On Fri, Sep 09, 2005 at 23:28:32 +0200, Arkadiusz Miskiewicz wrote:

> Do you know that here you are not talking about cvs vs svn but about how we 
> want to organise repository layout?

We don't. rpmbuild uses flat structure and so I want the repos.

> rpmbuild -bb --define _topdir somewhere
> 
> because you would have /packages/gcc/trunk/{SPECS,SOURCES} 

You are kidding, aren't you? I'm using rpmbuild a hundred times often
than fetching sources and milion times than reverting commit and you
want me to type these defines?

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

This script EXISTS. Give me a handy tool for svn.

> SPECS/SOURCES to nicer scheme and we should talk about that scheme. With new, 

IMHO current is nice.

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

So what? I want to checkout all the specs, I'm not interested in sources
or anything else.

> With the /packages you get some things and also loose some 
> things.

That's obvious. Particulary I don't get anything from what you're saying
for now.

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

I don't get it. Why is:

cvs ci SPECS/foo.spec SOURCES/foo.patch

worse than the same in svn?

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

Do you want me to write you 4-line script?

> It's single command with svn and  tens with cvs.

And we all are doing it every day... just use TAGging when working on
100 files.

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

Yeah, I'm evil.

> I remember complaints 
> from developers that files where copied by cvsadmin not as fast as developers 
> wanted.

Oh my god! Really!?

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

We're deleting such branches?

> Few days later you want to revert that and... 

...and I have never had such situation.

> 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

I'm doing it in separate directories.

echo NAC-branch > CVS/Tag

> svn: easy, separate dirs,

Yeah, separate - SPECS, SPECS-devel, SPECS-foo.

> 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 

And all clear. I don't like python at all;)

> 9. doing diffs
> cvs: problematic if you want to compare whole packages, easy for individual 

Hey, we're not working on sources, but on specs and patches.

> Please think about what could be done better.

If you give me tool for things I'm doing right now (as written), I won't
care about background.

-- 
GoTaR <priv0.onet.pl->gotar>        http://vfmg.sourceforge.net/
                                    http://tccs.sourceforge.net/