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

[wrobell]

On Thu, 2005-09-08 at 01:53 +0200, Jan Rekorajski wrote:
> On Wed, 07 Sep 2005, wrobell wrote:
> 
> > On Wed, 2005-09-07 at 11:03 +0200, Jan Rekorajski wrote:
> > > Example: http://svn.pld-linux.org/svn/rc-scripts
> > > I want to keep only trunk, branches and _some_ tags, tell me how to do
> > > it, and how to prevent svn up from getting all tags.
> > 
> > svn up trunk?
> > svn up tags/tagireallywant?
> > 
> > come on...
> 
> Ok, that's solved then, thanks. One more question - how to do 'svn up' in
> directory where I did checkouts so it will update all checked subdirs?
> With cvs all I need to do is `mkdir CVS ; echo $CVSROOT > CVS/Root ; cvs up`
> A recipe for svn much appreciated :)

1. create your own local repo
2. checkout it 
3. svn propedit svn:externals .
4. add tags, branches, whatever
5. svn up

the advantage: you will never fsck up anything with cvs up -A
(imho, but not tested with cvs)

> > > And the royal PITA, which svn is, is not worth it.
> > 
> > ... it is really hard to discuss with such arguments, which seem
> > to be matter of taste.
> > 
> > i think (let's skip svn for now), we need:
> > - to keep history of tags and branches
> 
> ok, I guess all versioning systems must have it, or do you mean
> dead/deleted tags and branches? What for?

yes. deleted tags and branches. i.e. when you merge DEVEL, delete
it, then for some reason  you want to compare HEAD with DEVEL
(i.e. something went wrong while merging).

> > - atomic commit (so we can commit patches and specs with one move
> >   and revert it easily later if there is a need)
> 
> Example?

svn ci -m "patches updated for 3.0" \
  SPECS/tetex.spec SOURCES/teTeX*patch

and then, later, you can easily see what exact changes
where made. good luck with cvs.

> > - ability to rename specs and patches without pain and loosing
> >   information and _without_administrator_ help
> 
> Maybe, but do we really do this that often?

not often. but happens from time to time. again: not only specs,
but very useful for renaming patches.

> > - check changes without making connection to remote server
> 
> And svn solves it how?

maybe i should put it this way: "check _local_ changes..."

svn diff|status|revert

http://svnbook.red-bean.com/en/1.1/apas03.html

> > these are my problems with cvs. svn solves them. 
> > 
> > svn gives us some advantages. disadvantages? any real, which makes life
> > really painful? let's talk but without "royal PITA", "i do not care
> > for lost information", "i do not care for renaming", etc. please.
> 
> One BIG disadvantege is that we will have to reorganize the entire repo
> into "one package" = "one svn dir" layout. And then it's either a
> fscking lot of copying svn-local-repo <-> ~/rpm/* or constant editing of
> ~/.rpmmacros. With current layout I can just checkout entire SPECS and
> SOURCES and work with any package on any branch easily.

i think, that we are able to create such structure (and even structures)
that it will be as easy as it is now and it will give us more options
(so yes, i see rpm/{SPECS,SOURCES} as _not_ obsoleted)

> And then, what "lost information"? And the argument about renaming is
> just making me laugh, we have more than 9400 specs, we needed to rename
> how much of them? 10? 20? Come on.

it is sick to ask admin, isn't it? please consider renaming of patches
too.

> > then, if svn is not solution for us, then what other alternatives
> > we can use? let's think about it, because cvs is not solution
> > for us.
> 
> Why it is not? I work with it from the beggining and I don't feel any
> need to switch, I haven't yet seen a versioning system that would give
> enough advantages that I'd consider switching.

i wrote reasons in other post. and there are people who think we
should switch and they (we) have real problems which would be
solved then.

  wrobell <wrobell at pld-linux.org>