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

Arkadiusz Miskiewicz arekm at pld-linux.org
Sat Sep 10 11:31:35 CEST 2005


On Saturday 10 of September 2005 02:59, Tomasz Pala wrote:
> 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.
I dont care what you want. Your help in developing PLD is marginal.

> > 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?
No, read again. Scripts needs to be written the same way as for cvs. svn it's 
not a super-machine-for-doing--exactly-what-pala-wants but simple scm system.

>
> > 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.
As I wrote already - it has to be written _before_ anything can happen. 

> > SPECS/SOURCES to nicer scheme and we should talk about that scheme. With
> > new,
>
> IMHO current is nice.
It's not because you have no idea which patch belongs (now or in past) to 
which spec etc. qboosh is catching many such cases and deletes unused files - 
with svn this is as easy as doing ls && less.


> So what? I want to checkout all the specs, I'm not interested in sources
> or anything else.
Use ./builder -f SPECS? Where builder has to be written.

> > > 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?
If you still don't understand what atomic commits are then talk with you is 
pointless.

> > > 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?
Yes, please.

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

> > I remember complaints
> > from developers that files where copied by cvsadmin not as fast as
> > developers wanted.
>
> Oh my god! Really!?
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?
Of course we are. You have no clue what's happening there.

> > Few days later you want to revert that and...
> ...and I have never had such situation.
Because you do (almost) nothing?

> > 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;)
There are other bindings. perl, java.

> > 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.
And so what? For merging rpm from head to ac-branch you need to review spec 
and _all_ patches. spec + patches is like sources, no difference.

> > 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.
Ehh, so this whole talk is pointless since such tool NEEDS to be written 
first.

-- 
Arkadiusz Miśkiewicz                    PLD/Linux Team
http://www.t17.ds.pwr.wroc.pl/~misiek/  http://ftp.pld-linux.org/



More information about the pld-devel-en mailing list