Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...) - Mailing list pgsql-patches

The intuitive understanding of a file is certainly something like "a
file called 'baz.c' residing at 'foo/bar/', which contains the BAZ
subsystem". Now, when renaming/moving a file such an intuitive
understanding is partially lost. UI-wise that's a problem which I
haven't ever seen solved well.

However, other SCM systems such as Subversion and Continuus (and our
to-be-released system Maint, and certainly others) treat files as
unique entities unrelated to their path, and thus don't have problems
with moves.

With regards to modes of working this, it boils down to two methods.
One is treating directories as first class entities (opposed to CVS
which treats dirs as semi-relevant appendices to real files), versioned
to contain a list of children, or simpler yet, to store the parent
directory as an meaningful attribute of an object. Both methods have
their pros and cons, the latter is somehow simpler to intuitively grasp
for people.

This doesn't really answer the question of what tool Postgres might
change to, but it seems that Subversion is a good tool one should
consider. And by golly, CVS is bad. Just consider the cons – having to
forbid renames in all but the most necessary cases – it just invites
cruft into any project.

d.
--
David Helgason,
Business Development et al.,
Over the Edge I/S (http://otee.dk)
Direct line +45 2620 0663
Main line +45 3264 5049

On 4. nov 2004, at 20:41, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@postgresql.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
>