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

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

From
Alvaro Herrera
Date:
On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Why not move it to src/tools, so no one gets the impression that it is
> > user code?
>
> I thought about that earlier, but concluded it wasn't worth the loss of
> CVS history.

I have counted three times you have said that in the recent past.  IMHO
this really screams of changing the SCM tool.

Can this be discussed for 8.1?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La felicidad no es mañana. La felicidad es ahora"


Re: [PATCHES] CVS should die (was: Possible make_oidjoins_check ...)

From
Tom Lane
Date:
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> Can this be discussed for 8.1?

It's been discussed, and rejected, several times already.  There aren't
any alternatives that are enough better than CVS to be worth the
changeover effort.

            regards, tom lane

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

From
"Marc G. Fournier"
Date:
On Thu, 4 Nov 2004, Alvaro Herrera wrote:

> On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> Why not move it to src/tools, so no one gets the impression that it is
>>> user code?
>>
>> I thought about that earlier, but concluded it wasn't worth the loss of
>> CVS history.

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


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

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

From
Tom Lane
Date:
"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

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

From
"Marc G. Fournier"
Date:
On Thu, 4 Nov 2004, 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.

Erk, yes, good point ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

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

From
Andrew Sullivan
Date:
On Thu, Nov 04, 2004 at 02:41:08PM -0500, Tom Lane wrote:
> 
> (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.)

I understood that the whole point of subversion was mostly to make
moving files easier.  It's number two in the feature list at the
subversion home page.  They say they version meta-data.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.                --Brad Holland


Re: CVS should die

From
Oliver Jowett
Date:
Tom Lane wrote:

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

You can also do a repository-side copy of the ,v file to the new
location, remove old tags & branches from that new copy, and 'cvs
delete' the old copy. That preserves history but the file should still
show up in the old location (and not also in the new location) when
older versions are checked out. In theory. It's all very hairy..

> (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.)

Subversion deals with this reasonably well. The main difference to CVS
is that it does not try to track multiple lines of development in a
particular file; instead, you make (internally cheap) copies *within*
the repository tree when you branch or tag.

Once you have that, it's much easier to track file copies and deletions,
as each path in the repository effectively has a linear history. A
rename is just a copy and delete.

See http://svnbook.red-bean.com/svnbook-1.0/ch04s02.html for some more
detail.

-O

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

From
Joerg Hessdoerfer
Date:
Hi,

On Thursday 04 November 2004 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

<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.hessdoerfer@sea-gmbh.com
WWW:  http://www.sea-gmbh.com

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

From
Russell Smith
Date:
On Fri, 5 Nov 2004 07:02 am, Marc G. Fournier wrote:
> On Thu, 4 Nov 2004, 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.
>
> Erk, yes, good point ...
You could always, physically copy the file to the new location. Giving you all the history in the new location
and run CVS delete on the only location.  I can't see how this is too different from the cvs remove/cvs add.
However you get to keep the history as well as keeping the old version.

The second problem still exists where it's in 2 locations in previous releases. unless you cvs remove the new copy from
those branches as well.  As always CVS is a bit messy with these things, but just throwing ideas on the pile that might
work.

Regards

Russell Smith

Re: CVS should die (was: Possible make_oidjoins_check

From
Neil Conway
Date:
[CC list trimmed]

On Fri, 2004-11-05 at 06:41, Tom Lane wrote:
> (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.)

Sure -- just about every "next generation" OSS version control tool gets
this right, or at least does a lot better than CVS -- i.e. svn,
monotone, arch, darchs, and possibly others I haven't heard of.

Gavin and I have been using Monotone for a few weeks now to manage some
development we're doing. I've been really impressed with it --
conceptually, it just "makes sense". Unfortunately the implementation is
currently too immature to consider moving the main development tree
onto, at least for the moment.

-Neil




Re: CVS should die

From
Gaetano Mendola
Date:
Neil Conway wrote:
> [CC list trimmed]
> 
> On Fri, 2004-11-05 at 06:41, Tom Lane wrote:
> 
>>(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.)
> 
> 
> Sure -- just about every "next generation" OSS version control tool gets
> this right, or at least does a lot better than CVS -- i.e. svn,
> monotone, arch, darchs, and possibly others I haven't heard of.
> 
> Gavin and I have been using Monotone for a few weeks now to manage some
> development we're doing. I've been really impressed with it --
> conceptually, it just "makes sense". Unfortunately the implementation is
> currently too immature to consider moving the main development tree
> onto, at least for the moment.

In SVN there is no concept of Branch, Label and so on, all these operations
are performed by "copy" if you want LABEL your source is enough create a
directory and copy all the source in that directory.
In order to emulate the way to work of CVS is enough follow these guidelines:
http://docs.codehaus.org/display/HAUS/How+to+Organize+a+Subversion+Repository

We are migrating from Clearcase to SVN and the only think we are going
to miss is the UCM process.


Regards
Gaetano Mendola




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

From
David Helgason
Date:
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
>


Re: CVS should die

From
Thomas Hallgren
Date:
Joerg Hessdoerfer wrote:
> <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>
<MoreAdvocacy>
Another compelling reason to use SVN is that one of their long term 
goals is to use an SQL backend. PostreSQL must be the absolute best 
choice for that, right? So knowledge of SVN and some future 
collaboration could perhaps be beneficial for both parties.

SVN is also targeted as a CVS replacement and a CVS user will feel very 
much at home.
</MoreAdvocacy>

Regards,
Thomas Hallgren



Re: [PATCHES] CVS should die

From
Neil Conway
Date:
Thomas Hallgren wrote:
> Another compelling reason to use SVN is that one of their long term
> goals is to use an SQL backend.

That is about as far from a "compelling reason" to use a particular
version control system as I can imagine.

-Neil

Re: [PATCHES] CVS should die

From
Andrew Dunstan
Date:

Neil Conway wrote:

> Thomas Hallgren wrote:
>
>> Another compelling reason to use SVN is that one of their long term 
>> goals is to use an SQL backend.
>
>
> That is about as far from a "compelling reason" to use a particular 
> version control system as I can imagine.
>
>

Yeah.

I see these considerations as being important:

. does tool x do what we need?
. is tool x FOSS software?
. is the benefit to be gained from moving to tool x worth the pain involved?

I'll repeat an observation I made (more or less) last time we had this 
discussion: the loudest voice in it belongs to those who actually use 
the repository most. When Tom or Bruce or Peter (for example) tell us we 
need to change I'll take lots more notice.

I have little doubt that we will one day move away from CVS. What we 
will move to is still open - and I don't yet see a reason to rush into 
the arms of Subversion.

cheers

andrew


Re: [PATCHES] CVS should die

From
Thomas Hallgren
Date:
Andrew Dunstan wrote:
> 
> 
> Neil Conway wrote:
> 
>> Thomas Hallgren wrote:
>>
>>> Another compelling reason to use SVN is that one of their long term 
>>> goals is to use an SQL backend.
>>
>>
>>
>> That is about as far from a "compelling reason" to use a particular 
>> version control system as I can imagine.
>>
>>
> 
> Yeah.
> 
> I see these considerations as being important:
> 
> . does tool x do what we need?
> . is tool x FOSS software?
> . is the benefit to be gained from moving to tool x worth the pain 
> involved?
>
Duh! Bad wording on my part. I didn't mean that their future use of SQL 
backend should be a criteria. So "compelling reason" was a bad choice of 
words.

What I meant was, that at some point, we might be able to help the SVN 
people reach their SQL objective and at the same time push for 
PostgreSQL as the best choice. If PostgreSQL uses SVN (for the reasons 
mentioned by Andrew), then some knowledge will be gained and 
relationships established that might make such a collaboration very natural.

Once a PostgreSQL based backend is well tested and very stable, 
PostgreSQL can make the switch to use it for their own production. From 
an SVN standpoint, it must be a perfect reference to be able to say 
"Look, PostgreSQL uses SVN with their own database to store their own 
code". A better proof of concept doesn't exist! From a PostgreSQL 
standpoint? Well SVN already have a high amount of users and it is 
growing rapidly, i.e. the visibility is great.

It also struck me that the requirements for an SCM backend store must be 
especially well handled by an MVCC type system. New data is added 
frequently but very rarely updated or deleted.

Regards,
Thomas Hallgren



Re: [PATCHES] CVS should die

From
Peter Eisentraut
Date:
Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan:
> I'll repeat an observation I made (more or less) last time we had this
> discussion: the loudest voice in it belongs to those who actually use
> the repository most. When Tom or Bruce or Peter (for example) tell us we
> need to change I'll take lots more notice.

I'm certainly open to considering subversion, although I have a certain 
traumatic experience with it that may or may not be related to the BDB 
backend that it uses.

I think for a start it would be nice if pgfoundry could optionally offer 
subversion (and/or arch) for source control, so that some developer groups 
and also our system administrators could get some experience with it.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Re: [PATCHES] CVS should die

From
Andrew Dunstan
Date:

Peter Eisentraut wrote:

>I think for a start it would be nice if pgfoundry could optionally offer 
>subversion (and/or arch) for source control, so that some developer groups 
>and also our system administrators could get some experience with it.
>
>  
>

I agree. We (the pgfoundry admins) will see what can be done - no 
promises at this stage.

cheers

andrew


Re: [PATCHES] CVS should die

From
Gaetano Mendola
Date:
Peter Eisentraut wrote:
> Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan:
> 
>>I'll repeat an observation I made (more or less) last time we had this
>>discussion: the loudest voice in it belongs to those who actually use
>>the repository most. When Tom or Bruce or Peter (for example) tell us we
>>need to change I'll take lots more notice.
> 
> 
> I'm certainly open to considering subversion, although I have a certain 
> traumatic experience with it that may or may not be related to the BDB 
> backend that it uses.
> 
> I think for a start it would be nice if pgfoundry could optionally offer 
> subversion (and/or arch) for source control, so that some developer groups 
> and also our system administrators could get some experience with it.

I good very start point is see if cvs2svn can handle the postgresql CVS without
errors.


Regards
Gaetano Mendola




Re: [PATCHES] CVS should die

From
Heikki Linnakangas
Date:
On Fri, 5 Nov 2004, Gaetano Mendola wrote:

> Peter Eisentraut wrote:
>
>> I'm certainly open to considering subversion, although I have a certain 
>> traumatic experience with it that may or may not be related to the BDB 
>> backend that it uses.
>> 
>> I think for a start it would be nice if pgfoundry could optionally offer 
>> subversion (and/or arch) for source control, so that some developer groups 
>> and also our system administrators could get some experience with it.
>
> I good very start point is see if cvs2svn can handle the postgresql CVS 
> without
> errors.

I tried that yesterday out of curiosity. It had problems with 3 files 
which I removed manually:

/pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v
/pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v
/pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle.pl,v

Otherwise, no problems.

Interestingly, the subversion repository is 585MB, and the CVS repository 
is only 260MB, so apparently Subversion is not very good at compressing 
the repository. Not that it matters, though.

FWIW, I think Peter's idea of offering Subversion as an alternative in 
pgfoundry is very good.

I also agree with Andrew's observation that it's really up to the 
committers since they are the ones that have to work with whatever system 
we have.

I like subversion very much, but one thing that troubles me a bit is the 
number of extra libraries required to compile and run it. Also, is there 
pre-compiled binaries for all the platforms that PostgreSQL supports?

- Heikki


Re: [PATCHES] CVS should die

From
"Joshua D. Drake"
Date:
Heikki Linnakangas wrote:

> On Fri, 5 Nov 2004, Gaetano Mendola wrote:
>
>> Peter Eisentraut wrote:
>>
>>> I'm certainly open to considering subversion, although I have a
>>> certain traumatic experience with it that may or may not be related
>>> to the BDB backend that it uses.
>>>
>>> I think for a start it would be nice if pgfoundry could optionally
>>> offer subversion (and/or arch) for source control, so that some
>>> developer groups and also our system administrators could get some
>>> experience with it.
>>
>>
>> I good very start point is see if cvs2svn can handle the postgresql
>> CVS without
>> errors.
>
>
> I tried that yesterday out of curiosity. It had problems with 3 files
> which I removed manually:
>
> /pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v
> /pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v
> /pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle.pl,v
>
> Otherwise, no problems.
>
> Interestingly, the subversion repository is 585MB, and the CVS
> repository is only 260MB, so apparently Subversion is not very good at
> compressing the repository. Not that it matters, though.
>
Subversion, I believe uses SleepycatDb (eg Db4). Thus it isn't flat
files like CVS.


>
> I also agree with Andrew's observation that it's really up to the
> committers since they are the ones that have to work with whatever
> system we have.
>
> I like subversion very much, but one thing that troubles me a bit is
> the number of extra libraries required to compile and run it. Also, is
> there pre-compiled binaries for all the platforms that PostgreSQL
> supports?

Doubtful. Also there are known issues with Subversion on >FC1 if you are
running newer versions of it. You have to compile specially with
--without-posix-mutexes (I think that was the flag).

Sincerely,

Joshua D. Drake


>
> - Heikki
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster



--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL


Attachment

Re: [PATCHES] CVS should die

From
Gaetano Mendola
Date:
Heikki Linnakangas wrote:

> I tried that yesterday out of curiosity. It had problems with 3 files 
> which I removed manually:
> 
> /pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v
> /pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v
> /pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle.pl,v
> 
> Otherwise, no problems.
> 
> Interestingly, the subversion repository is 585MB, and the CVS 
> repository is only 260MB, so apparently Subversion is not very good at 
> compressing the repository. Not that it matters, though.
> 
> FWIW, I think Peter's idea of offering Subversion as an alternative in 
> pgfoundry is very good.

Mmm, do you mean createing periodically "snapshot"? Yes this could be
a good idea.

> I also agree with Andrew's observation that it's really up to the 
> committers since they are the ones that have to work with whatever 
> system we have.

That's true, but is really sad see Tom Lane think twice to move a file or
not because CVS.

> I like subversion very much, but one thing that troubles me a bit is the 
> number of extra libraries required to compile and run it. Also, is there 
> pre-compiled binaries for all the platforms that PostgreSQL supports?

I don't know about the server, but for sure what is more important here is the
client side and now that the win environment matter more then before,  I have to
say that TortoiseSVN ( tortoisesvn.tigris.org ) is much better then WinCVS.


Regards
Gaetano Mendola




















Re: [PATCHES] CVS should die

From
Ian Barwick
Date:
On Fri, 5 Nov 2004 16:22:55 +0100, Peter Eisentraut <peter_e@gmx.net> wrote:
> Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan:
> > I'll repeat an observation I made (more or less) last time we had this
> > discussion: the loudest voice in it belongs to those who actually use
> > the repository most. When Tom or Bruce or Peter (for example) tell us we
> > need to change I'll take lots more notice.
> 
> I'm certainly open to considering subversion, although I have a certain
> traumatic experience with it that may or may not be related to the BDB
> backend that it uses.

Aha, glad I'm not the only one. Version 1.1 has a flat-file based
backend which is not prone to BDB-permission-related problems, see:
http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.4 .
It's only been around a few months though and the docs mention
possible issues with scalability.

Ian Barwick
barwick@gmail.com


Re: [PATCHES] CVS should die

From
Heikki Linnakangas
Date:
On Fri, 5 Nov 2004, Gaetano Mendola wrote:

> Heikki Linnakangas wrote:
>
>> FWIW, I think Peter's idea of offering Subversion as an alternative in 
>> pgfoundry is very good.
>
> Mmm, do you mean createing periodically "snapshot"? Yes this could be
> a good idea.

No, I mean that each project could choose to use either cvs or svn, like 
they do at Apache.

Sure, if you could have both, that would be even better.

>> I like subversion very much, but one thing that troubles me a bit is the 
>> number of extra libraries required to compile and run it. Also, is there 
>> pre-compiled binaries for all the platforms that PostgreSQL supports?
>
> I don't know about the server, but for sure what is more important here is 
> the
> client side and now that the win environment matter more then before,  I have 
> to
> say that TortoiseSVN ( tortoisesvn.tigris.org ) is much better then WinCVS.

True. Looking at the Subversion downloads page, they seem to have binaries 
for various Linux distributions, FreeBSD, NetBSD and OpenBSD, Solaris, 
Mac OS X and Win32. According to the supported platforms chapter in 
pgsql documentation, we also support AIX, BSD/OS, HP-UX, IRIX, Tru64 
UNIX, UnixWare, and Linux on Alpha, arm41, m64, MIPS, PPC, S/390 and 
Sparc.

Developers on those platforms would have to compile subversion themselves, 
or compile pgsql from source tarballs.

Have you looked at TortoiseCVS (www.tortoisecvs.org)? I think TortoiseSVN 
is a fork of that.

- Heikki


Re: [PATCHES] CVS should die

From
Gaetano Mendola
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Heikki Linnakangas wrote:

| Have you looked at TortoiseCVS (www.tortoisecvs.org)? I think
| TortoiseSVN is a fork of that.

I didn't know the existence, is not even listed in the subproject
on CVS home page, I discovered TortoiseSVN on the Subversion home
page.


Regards
Gaetano Mendola



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBi9bJ7UpzwH2SGd4RAgraAKCcNLaMJPPjVxfqRQ1yGG2+GssiAACeJFg3
zULofgK2ouUum3wNSjUmG3U=
=Bq/a
-----END PGP SIGNATURE-----



Re: [PATCHES] CVS should die

From
Tom Lane
Date:
Ian Barwick <barwick@gmail.com> writes:
> Aha, glad I'm not the only one. Version 1.1 has a flat-file based
> backend which is not prone to BDB-permission-related problems, see:
> http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.4 .
> It's only been around a few months though and the docs mention
> possible issues with scalability.

One of the reasons I'm disinclined to move is that none of the proposed
alternatives seem especially, um, mature.  AFAIK this project has never
had CVS lose any data in the eight years we've used it.  I'd want a
comparable level of trust in any replacement SCM, and I haven't got it.
        regards, tom lane


Re: [PATCHES] CVS should die

From
Andrew McMillan
Date:
On Fri, 2004-11-05 at 15:37 -0500, Tom Lane wrote:
>
> One of the reasons I'm disinclined to move is that none of the proposed
> alternatives seem especially, um, mature.  AFAIK this project has never
> had CVS lose any data in the eight years we've used it.  I'd want a
> comparable level of trust in any replacement SCM, and I haven't got it.

A very sane reason.  I've lost my share of stuff with SVN in trialling
it, but we are switching our company over to Arch, which seems to offer
significantly more benefits.  From our trialling of it, I think it has a
more robust and mature repository structure too.

Watching the PostgreSQL team developing I would think that Arch would
provide much better support for the developers than SVN would.

Switching to Arch is more work, but it also offers a lot more benefits -
including the opportunity for individuals to maintain their own trees,
and be able to work out which patchsets from someone else's tree have
not been applied.  If anything is going to become the open-source
BitKeeper it will be this, I think.

Cheers,                Andrew.

-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ  Ltd,  PO Box 11-053, Manners St,  Wellington
WEB: http://catalyst.net.nz/            PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201      MOB: +64(272)DEBIAN      OFFICE: +64(4)499-2267                    Planning an election?  Call
us!
-------------------------------------------------------------------------


Re: [PATCHES] CVS should die

From
Thomas Hallgren
Date:
Andrew McMillan wrote:
> Switching to Arch is more work, but it also offers a lot more benefits -
> including the opportunity for individuals to maintain their own trees,
> and be able to work out which patchsets from someone else's tree have
> not been applied.  If anything is going to become the open-source
> BitKeeper it will be this, I think.
> 
For those interested in SVN versus arch, I found the following from Tom 
Lord (the guy behind Arch)

http://web.mit.edu/ghudson/thoughts/diagnosing

and a reply from Greg Hudson (SVN developer)

http://web.mit.edu/ghudson/thoughts/undiagnosing.

Regards,
Thomas Hallgren



Re: CVS should die

From
Thomas Hallgren
Date:
Tom,
> (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.)
> 
I've been working with a few SCM's and IMHO only one of them really 
handles this really well. That's ClearCase. I'm well aware that 
ClearCase is not an option but I though it could still be interesting to 
know how this can be managed when done right.

In ClearCase everything (both files and directories) are "elements". A 
directory is a version of an element and it contains versions of other 
elements. It's not very different from Unix and I-nodes although 
everything is of course versioned.

Subversion claims they handle moves pretty well. When I checked it out, 
it turns out that a move is a copy (versions and all) followed by a 
delete, thus maintaining version history at both locations. I'd 
recommend anyone who think CVS is insufficient due to file moves to 
investigate subversion.

Regards,
Thomas Hallgren



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

From
Steve Crawford
Date:
> 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.

Interesting reading:
http://better-scm.berlios.de/comparison/comparison.html
http://zooko.com/revision_control_quick_ref.html

Cheers,
Steve


Re: [PATCHES] CVS should die

From
Anand Kumria
Date:
On Sat, 06 Nov 2004 11:53:13 +0100, Thomas Hallgren wrote:

> Andrew McMillan wrote:
>> Switching to Arch is more work, but it also offers a lot more benefits -
>> including the opportunity for individuals to maintain their own trees,
>> and be able to work out which patchsets from someone else's tree have
>> not been applied.  If anything is going to become the open-source
>> BitKeeper it will be this, I think.
>> 
> For those interested in SVN versus arch, I found the following from Tom 
> Lord (the guy behind Arch)
> 
> http://web.mit.edu/ghudson/thoughts/diagnosing
> 
> and a reply from Greg Hudson (SVN developer)
> 
> http://web.mit.edu/ghudson/thoughts/undiagnosing.
> 

There is a fairly detailed comparison in the GNU Arch wiki as well.

<URL: http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison>

Note: if you're a postgres committer you may have more luck seeking out
your nearest SCM advocate -- almost all of them would regard Postgres
migrating to their preferred SCM as a 'win' -- let them work for you by
walking you through things.

Cheers,
Anand



Re: CVS should die

From
Thomas Hallgren
Date:
Tom Lane wrote:
> ... There aren't
> any alternatives that are enough better than CVS to be worth the
> changeover effort.
> 
I've done some research over the last couple of days for a fairly big 
project where we face the challenges of breaking up a monolith into 
modules and consequently will be forced to move a lot of files. I now 
second Tom's opinion. Here's why:

Subversion doesn't move files. They copy and delete. So if you have 
parallel work on a file that is "moved", you are headed for problems. 
See threads:

"Question about rename" on users@subversion.tigris.org
news://news.gmane.org:119/cmsqci$s9q$1@sea.gmane.org

and

"Misinforming the user on rename with local changes" 
dev@subversion.tigris.org
news://news.gmane.org:119/419379F3.5070302@ftml.net

What I find especially intriguing is that although Subversion have 
version controlled directories, they still identify the content of the 
files using the location in the repository rather than using a globally 
unique identifier. Didn't they anticipate files being moved around and 
perhaps linked?

This thread started due to CVS problems with moving files and Subversion 
will perhaps get there eventually but IMHO they are certainly not there yet.

GNU-Arch seems promising in some respects. It really can rename files 
and track them using an id, but it doesn't run on Windows without Cygwin 
(and even then not too well it seems). Personally I dislike the fact 
that the author seems somewhat religious about free software and hostile 
towards Windows instead of focusing on delivering a portable solution. 
In my case, the fact that GNU-Arch is not portable is reason enough to 
discard it as a viable alternative and I think it would be unfortunate 
if PostgreSQL locked Windows users out from repository access.

The other Open Source alternatives are, IMHO not mature enough to be 
considered for serious projects yet.

I wish ClearCase was fast, free, and suitable for distributed 
development :-) Unfortunately it's slow, expensive, and extremely 
network intensive. My approach will be to wait and perhaps contribute to 
Subversion if I get some time left. They really need a great database 
backend.

Regards,
Thomas Hallgren



Re: CVS should die

From
Andrew Dunstan
Date:

Thomas Hallgren wrote:

>
> GNU-Arch seems promising in some respects. It really can rename files 
> and track them using an id, but it doesn't run on Windows without 
> Cygwin (and even then not too well it seems). Personally I dislike the 
> fact that the author seems somewhat religious about free software and 
> hostile towards Windows instead of focusing on delivering a portable 
> solution. In my case, the fact that GNU-Arch is not portable is reason 
> enough to discard it as a viable alternative and I think it would be 
> unfortunate if PostgreSQL locked Windows users out from repository 
> access.
>
>

s/unfortunate/totally unacceptable/


cheers

andrew


Re: CVS should die

From
Travis P
Date:
On Nov 13, 2004, at 6:20 PM, Thomas Hallgren wrote:

> "Question about rename" on users@subversion.tigris.org
> news://news.gmane.org:119/cmsqci$s9q$1@sea.gmane.org

Thomas (Hallgren):  Unfortunately, my efforts to get Thunderbird to do 
something useful with that URL have been unsuccessful and I can't find 
the thread on the (usable) mailing list archive ( don't use the 
tigris.org archive; use http://svn.haxx.se/ ).

> "Misinforming the user on rename with local changes" 
> dev@subversion.tigris.org
> news://news.gmane.org:119/419379F3.5070302@ftml.net

Might be easier to read with a browser here:  http://svn.haxx.se/dev/archive-2004-11/index.shtml

Yes, looks like it could be a potential problem/inconvenience if a file 
is both moved and altered simultaneously.

I see the risk of problems as similar to those that if two people edit 
the same section of the same file at the same time, complicated 
conflicts could emerge.  You could avoid this problem using 
Lock-Modify-Unlock rather than Copy-Modify-Merge.  Some people do.  
Others (many CVS users) choose the productivity gains by using 
Copy-Modify-Merge and then deal with the eventual problem when/if it 
shows up.

It is too bad the Subversion design didn't anticipate this such that 
it's not a problem at all, but in many environments, it may not be much 
of an issue.

> This thread started due to CVS problems with moving files and 
> Subversion will perhaps get there eventually but IMHO they are 
> certainly not there yet.

It is worth noting that there is already huge improvement in this area.  There's a baby in that bathwater. :-)  It's
mademy life much easier, 
 
particularly for Java development where refactoring requires renames 
and moves of files and directories more often than with some other 
languages like C/C++.

I'm not really advocating a switch if you don't think it's worth it.  
Just hoping to contribute constructively to the discussion where the 
worth of the costs/benefits are measured by others.

Back to playing with the 8 beta for me,  :-)
--Travis



Re: CVS should die

From
kaz@ashi.footprints.net (Kaz Kylheku)
Date:
twp@castle.fastmail.fm (Travis P) wrote in message news:<F54111AA-35EB-11D9-B14F-003065F9DAF8@castle.fastmail.fm>...
> > "Misinforming the user on rename with local changes" 
> > dev@subversion.tigris.org
> > news://news.gmane.org:119/419379F3.5070302@ftml.net
> 
> Might be easier to read with a browser here:
>    http://svn.haxx.se/dev/archive-2004-11/index.shtml
> 
> Yes, looks like it could be a potential problem/inconvenience if a file 
> is both moved and altered simultaneously.

You guys should check out the software that I developed called
Meta-CVS.

It creates a version control system that has directory structure
versioning, over top of the file versioning semantics provided by CVS.

Meta-CVS does not have problems with these corner cases, by design.

> I see the risk of problems as similar to those that if two people edit 
> the same section of the same file at the same time, complicated 
> conflicts could emerge.

In Meta-CVS, conflicts in the directory structure are exactly like
these conflicts, because the directory structure is marked up as a
straightforward text document.

When conflicts occur, you can read that document and it's obvious that
one user wanted to rename foo.c to src/foo.c, whereas another one
wanted to rename it to foobar.c.

Meta-CVS completely separates the directory structure from the files,
in the classic way: just like Unix file systems, and network file
systems like NFS and others. A file is known by an 128 bit identifier
encoded as text in hexadecimal.

So for example, even picking up a deletion to a locally modified file
is safe.

Suppose you have been editing a document foo.txt, do a ``mcvs up'' and
it's deleted. Your changes are still safe and can be committed. All
that happened was that your foo.txt was unlinked from the directory
structure. The real object, still exists, and has all your changes. It
can be committed to CVS. Independently of that action, you can
re-introduce your object into the directory structure: just change the
markup document (a file called MAP in the MCVS directory at the root
of your project) and then run ``mcvs up''. Meta-CVS will notice the
change, and link the file into the appropriate place, as requested by
the new markup. You can commit that markup change, and the file will
reappear in people's sandboxes when they pick it up.

> It is too bad the Subversion design didn't anticipate this such that 
> it's not a problem at all, but in many environments, it may not be much 
> of an issue.

Fortunately, I anticipated the problem before I laid down the first
line of code.


Re: CVS should die

From
Thomas Hallgren
Date:
Travis P wrote:

> Thomas (Hallgren):  Unfortunately, my efforts to get Thunderbird to do 
> something useful with that URL have been unsuccessful and I can't find 
> the thread on the (usable) mailing list archive ( don't use the 
> tigris.org archive; use http://svn.haxx.se/ ).

Thanks Travis. I'm not at all friend with Tigris mailing list archives 
and I wasn't aware of haxx.se. Here are the relevant links:

http://svn.haxx.se/dev/archive-2004-11/0505.shtml
http://svn.haxx.se/users/archive-2004-11/0433.shtml
http://svn.haxx.se/users/archive-2004-11/0445.shtml

Regards,
Thomas Hallgren