On Thursday 04 November 2004 20:41, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > why would we lose CVS history?  I can physically move the files in
> > /cvsroot to accomplish this ... just tell me what needs to move, and to
> > where ...
> If you physically move the files, that would retroactively change their
> placement in back versions, no?  ie, it would appear that all previous
> releases had had 'em under src/tools as well.
> AFAICS the only nondestructive way to do this is to cvs delete and cvs
> add, with a commit comment saying where the files were moved from.  Then
> when you are looking at them in CVS, you'd have to navigate over to the
> previous location (by hand, probably; the commit comment isn't going to
> automate this for you) and look in the Attic to read the prior CVS history.
> It's not impossible, certainly, but it discourages moving files for less
> than the very best of reasons.
> (I'm rather interested to know whether any other SCMs have a better
> solution to this problem, and if so what it is.  It's not obvious how
> to do better.)
>    regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend

Yes, some do. At least SVN (Subversion) can handle moves very well, and 
especially it doesn't loose history on moves/renames.
SVN holds it's repo entries in a database like 'filesystem', which can be 
backed by BDB4 or flat files (as of 1.1).
SVN has proven to be stable in many OSS projects, and vastly superior over CVS 
especially in handling multi-GB projects containing binary files in our 

I refrain from listing all the advantages, if interested, have a look for 
yourself at http://subversion.tigris.org


Having one file in the repo per working copy file like with CVS is an obvious, 
but also obviously limited approach.  

Leading SW developer  - S.E.A GmbH
WWW:  http://www.sea-gmbh.com

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to