Skip site navigation (1) Skip section navigation (2)

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

From: David Helgason <david(at)uti(dot)is>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,"Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>,Neil Conway <neilc(at)samurai(dot)com>,Hackers <pgsql-hackers(at)postgresql(dot)org>,Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>,Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>,Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: CVS should die (was: Possible make_oidjoins_check ...)
Date: 2004-11-05 00:12:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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.

David Helgason,
Business Development et al.,
Over the Edge I/S (
Direct line +45 2620 0663
Main line +45 3264 5049

On 4. nov 2004, at 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

In response to


pgsql-hackers by date

Next:From: Christopher BrowneDate: 2004-11-05 01:57:34
Subject: Re: CVS should die
Previous:From: Gavin SherryDate: 2004-11-04 23:09:05
Subject: Re: [pgsql-www] pg_autovacuum is nice ... but ...

pgsql-patches by date

Next:From: Christopher BrowneDate: 2004-11-05 01:57:34
Subject: Re: CVS should die
Previous:From: Gaetano MendolaDate: 2004-11-04 22:54:19
Subject: Re: CVS should die

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group