On Sun, 13 May 2007, Radoslaw Zielinski wrote: > Patryk Zawadzki <[EMAIL PROTECTED]> [13-05-2007 23:09]: > > On 5/13/07, Radoslaw Zielinski <[EMAIL PROTECTED]> wrote: > > > Patryk Zawadzki <[EMAIL PROTECTED]> [13-05-2007 21:58]: > > > > Why? > > > Why what? > > Why do you believe all RCS tools suck? > > Because I haven't seen one that doesn't.
I agree here, they just do it diffrent ways ;) > > > > What are the problems? > > > Off the top of my head: > > > - excessive metadata (CVS/Entries is just a few dozen bytes per file) > > Disk space is cheap. > > That's no reason for wasting it. Two copies + metadata in case of > SVN is over the line (one copy with SVK). Come on, the repo will not magically grow by enormous amounts, [EMAIL PROTECTED] repo]$ du -hsc SOURCES SPECS ; du -hs packages 183M SOURCES 64M SPECS 246M total 436M packages And the size increase is mainly because of 1) below. > > > - $Log$ > > No need for it as rpm can build the log from the SVN log output. > > svn log is an online operation. Yeah, svn sucks here. But VCS change is for another time. > > > If you know the answer (or so you think), what's the point of asking? > > You didn't provide any real life issues and all that were raised on > > this list could easily be solved with a small potion of bash magic. > > I'll wait for the proponents of the change to provide the `real life > issues' which would disappear. I mean, the ones which can't be solved > with bash magic. 1) files that belong to more than one package, you either have to _know_ the involved packages and keep them synchronized or you will have a mess 2) orphans, we have ~900 files in SOURCES that don't belong to any package currently 3) guesswork in case you work with more packages at once or with the whole repo - hmm, file adfgasdfgda.patch does belong to what package? And those were just everyday, common issues. Janek -- Jan Rekorajski | ALL SUSPECTS ARE GUILTY. PERIOD! baggins<at>mimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio _______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
