Re: CVS should die (was: Possible make_oidjoins_check ...)

Hi,

On Thursday 04 November 2004 20:41, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> 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

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

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

</Advocacy>

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

Greetings,
Jörg
--
Leading SW developer - S.E.A GmbH
Mail: joerg(dot)hessdoerfer(at)sea-gmbh(dot)com
WWW: http://www.sea-gmbh.com