pgman wrote:
> Peter Eisentraut wrote:
> > John Gray writes:
> > 
> > > dbcommands.c	rename to database.c (see below)
> > > indexcmds.c	rename to index.c (see below)
> > 
> > Might as well keep these.  They don't hurt anyone just because they spell
> > a little differently.
> 
> I disagree.  If we are cleaning, let's clean.  *cmd* is redundant.  The
> contents of the files will be quite different anyway.

Good point about keeping CVS logs.  Can't we just move the CVS file to
another name, create an empty file in its place, then delete it.  I
thought that would move the history.  We have never done it but I would
think there is a way to do it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 27 Feb 2002 00:31:34 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Refactoring of command.c
A simple copy works quite well.  Bit of a waste of space but you
preserve the history in both locations.

An empty file will not work.  If someone were to check out an older
version it would be broken.
--
Rod Taylor

This message represents the official view of the voices in my head

----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: <pgman@candle.pha.pa.us>
Cc: "Peter Eisentraut" <peter_e@gmx.net>; "John Gray"
<jgray@azuli.co.uk>; <pgsql-hackers@postgresql.org>
Sent: Wednesday, February 27, 2002 12:31 AM
Subject: Re: [HACKERS] Refactoring of command.c


> pgman wrote:
> > Peter Eisentraut wrote:
> > > John Gray writes:
> > >
> > > > dbcommands.c rename to database.c (see below)
> > > > indexcmds.c rename to index.c (see below)
> > >
> > > Might as well keep these.  They don't hurt anyone just because
they spell
> > > a little differently.
> >
> > I disagree.  If we are cleaning, let's clean.  *cmd* is redundant.
The
> > contents of the files will be quite different anyway.
>
> Good point about keeping CVS logs.  Can't we just move the CVS file
to
> another name, create an empty file in its place, then delete it.  I
> thought that would move the history.  We have never done it but I
would
> think there is a way to do it.
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania
19026
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to
majordomo@postgresql.org)
>


Wed, 27 Feb 2002 06:50:38 -0500
"Rod Taylor" <rbt@zort.ca>
Re: Refactoring of command.c
"Rod Taylor" <rbt@zort.ca> writes:
> A simple copy works quite well.  Bit of a waste of space but you
> preserve the history in both locations.

If you do that, the copied file will appear to CVS to be part of older
versions, no?

			regards, tom lane

Wed, 27 Feb 2002 10:13:35 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Refactoring of command.c 
It will, but I've always been able to make the assumption it won't be
compiled in as the make files always specified exactly which ones to
compile (and would ignore the new 'stray').

Perhaps the best way to approach this would be to ask the FreeBSD
'repo' people what they do -- as they do this kind of stuff quite
frequently.
--
Rod Taylor

This message represents the official view of the voices in my head

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Rod Taylor" <rbt@zort.ca>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>; "Peter Eisentraut"
<peter_e@gmx.net>; "John Gray" <jgray@azuli.co.uk>;
<pgsql-hackers@postgresql.org>
Sent: Wednesday, February 27, 2002 10:13 AM
Subject: Re: [HACKERS] Refactoring of command.c


> "Rod Taylor" <rbt@zort.ca> writes:
> > A simple copy works quite well.  Bit of a waste of space but you
> > preserve the history in both locations.
>
> If you do that, the copied file will appear to CVS to be part of
older
> versions, no?
>
> regards, tom lane
>


Wed, 27 Feb 2002 10:21:27 -0500
"Rod Taylor" <rbt@zort.ca>
Re: Refactoring of command.c 
Dug the below out of googles cache -- it's what the BSDs do for moving
files in cvs.

What is a repo-copy?
A repo-copy (which is a short form of ``repository copy'') refers to
the direct copying of files within the CVS repository.

Without a repo-copy, if a file needed to be copied or moved to another
place in the repository, the committer would run cvs add to put the
file in its new location, and then cvs rm on the old file if the old
copy was being removed.

The disadvantage of this method is that the history (i.e. the entries
in the CVS logs) of the file would not be copied to the new location.
As the FreeBSD Project considers this history very useful, a
repository copy is often used instead. This is a process where one of
the repository meisters will copy the files directly within the
repository, rather than using the cvs program.

--
Rod Taylor

This message represents the official view of the voices in my head

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Rod Taylor" <rbt@zort.ca>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>; "Peter Eisentraut"
<peter_e@gmx.net>; "John Gray" <jgray@azuli.co.uk>;
<pgsql-hackers@postgresql.org>
Sent: Wednesday, February 27, 2002 10:13 AM
Subject: Re: [HACKERS] Refactoring of command.c


> "Rod Taylor" <rbt@zort.ca> writes:
> > A simple copy works quite well.  Bit of a waste of space but you
> > preserve the history in both locations.
>
> If you do that, the copied file will appear to CVS to be part of
older
> versions, no?
>
> regards, tom lane
>


Wed, 27 Feb 2002 10:24:26 -0500
"Rod Taylor" <rbt@zort.ca>
Re: Refactoring of command.c 
"Rod Taylor" <rbt@zort.ca> writes:
> Dug the below out of googles cache -- it's what the BSDs do for moving
> files in cvs.

> What is a repo-copy?
> A repo-copy (which is a short form of ``repository copy'') refers to
> the direct copying of files within the CVS repository.

Yeah, I think that's what we discussed the last time the question came
up.

It seems awfully wrongheaded to me.  IMHO, the entire point of a CVS
repository is to store past states of your software, not only the
current state.  Destroying the accurate representation of your historical
releases is a poor tradeoff for making it a little easier to find the
log entries for code that's been moved around.  What's the point
of having history, if it's not accurate?

			regards, tom lane

Wed, 27 Feb 2002 14:06:37 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Refactoring of command.c 
> > What is a repo-copy?
> > A repo-copy (which is a short form of ``repository copy'') refers to
> > the direct copying of files within the CVS repository.
>
> Yeah, I think that's what we discussed the last time the question came
> up.
>
> It seems awfully wrongheaded to me.  IMHO, the entire point of a CVS
> repository is to store past states of your software, not only the
> current state.  Destroying the accurate representation of your historical
> releases is a poor tradeoff for making it a little easier to find the
> log entries for code that's been moved around.  What's the point
> of having history, if it's not accurate?

Sounds like it's time to move to using 'arch':

http://www.regexps.com/#arch

Supports everything that CVS doesn't, including rename events...

BTW - I'm not _seriously_ suggesting this change - but it would be cool,
wouldn't it?

People could start their own local branches which are part of the global
namespace, easily merge them in, etc...

Chris


Thu, 28 Feb 2002 09:18:39 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Arch (was RE: Refactoring of command.c )
On Thu, 28 Feb 2002, Christopher Kings-Lynne wrote:

[Shame on Christopher for breaking attributions]

> > > What is a repo-copy?
> > > A repo-copy (which is a short form of ``repository copy'') refers to
> > > the direct copying of files within the CVS repository.
> >
> > Yeah, I think that's what we discussed the last time the question came
> > up.
> >
> > It seems awfully wrongheaded to me.  IMHO, the entire point of a CVS
> > repository is to store past states of your software, not only the
> > current state.  Destroying the accurate representation of your historical
> > releases is a poor tradeoff for making it a little easier to find the
> > log entries for code that's been moved around.  What's the point
> > of having history, if it's not accurate?
>
> Sounds like it's time to move to using 'arch':

I see this going down the road of a religious debate, and to prove the
point, I bring up BitKeeper:

http://www.bitkeeper.com

> http://www.regexps.com/#arch
>
> Supports everything that CVS doesn't, including rename events...

So does BitKeeper :)

> BTW - I'm not _seriously_ suggesting this change - but it would be cool,
> wouldn't it?
>
> People could start their own local branches which are part of the global
> namespace, easily merge them in, etc...

This seems quite pointless for PostgreSQL's development.

C'est la vie.


-- 
Dominic J. Eidson
                                        "Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/              http://www.the-infinite.org/~dominic/


Wed, 27 Feb 2002 22:25:31 -0600 (CST)
"Dominic J. Eidson" <sauron@the-infinite.org>
Re: Arch (was RE: Refactoring of command.c )
"Dominic J. Eidson" <sauron@the-infinite.org> writes:
> On Thu, 28 Feb 2002, Christopher Kings-Lynne wrote:
>> Sounds like it's time to move to using 'arch':

> I see this going down the road of a religious debate, and to prove the
> point, I bring up BitKeeper:

Hmm.  I'd surely be the last to claim that CVS is the be-all and end-all
of software archiving systems.  But is BitKeeper, or arch, or anything
else enough better to justify the pain of switching?  This is intended
as an honest question, not flamebait --- I haven't looked closely at
the alternatives.

			regards, tom lane

Wed, 27 Feb 2002 23:44:23 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Arch (was RE: Refactoring of command.c ) 
> I see this going down the road of a religious debate, and to prove the
> point, I bring up BitKeeper:
>
> http://www.bitkeeper.com

I admit I don't know much about bitkeeper, except its license is a bit
weird...

> > http://www.regexps.com/#arch
> >
> > Supports everything that CVS doesn't, including rename events...
>
> So does BitKeeper :)
>
> > BTW - I'm not _seriously_ suggesting this change - but it would be cool,
> > wouldn't it?
> >
> > People could start their own local branches which are part of the global
> > namespace, easily merge them in, etc...
>
> This seems quite pointless for PostgreSQL's development.

NOT TRUE!!!

Imagine you want to develop a massive new feature for Postgres.  You just
create a branch on your own machine, do all your changes, commits, etc. and
keep it current with the main branch. Then, you can merge it back into the
main tree...  That way you can have a history of commits on your own branch
of the repo!

Disclaimer:  Have only read docs, not actually _used_ 'arch'... :(

Chris


Thu, 28 Feb 2002 17:00:00 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: Arch (was RE: Refactoring of command.c )
On Thu, 2002-02-28 at 06:44, Tom Lane wrote:

> Hmm.  I'd surely be the last to claim that CVS is the be-all and end-all
> of software archiving systems.  But is BitKeeper, or arch, or anything
> else enough better to justify the pain of switching?  This is intended
> as an honest question, not flamebait --- I haven't looked closely at
> the alternatives.

There was a discussion on Slashdot a couple of weeks ago, with (as
usual) some interesting comments out of the lot. It's at
http://slashdot.org/comments.pl?sid=27540&threshold=4&mode=flat
including comments from Subversion's Karl Fogel.

-- 
Alessio F. Bragadini		alessio@albourne.com
APL Financial Services		http://village.albourne.com
Nicosia, Cyprus		 	phone: +357-22-755750

"It is more complicated than you think"
		-- The Eighth Networking Truth from RFC 1925


28 Feb 2002 12:14:32 +0200
Alessio Bragadini <alessio@albourne.com>
Re: Arch (was RE: Refactoring of command.c )
> Imagine you want to develop a massive new feature for Postgres.  You
just
> create a branch on your own machine, do all your changes, commits,
etc. and
> keep it current with the main branch. Then, you can merge it back
into the
> main tree...  That way you can have a history of commits on your own
branch
> of the repo!

The same thing can be accomplished with CVS as well -- it's just not
as pretty.   There is a reason that the FreeBSD group uses $FreeBSD$
and leaves $Id$ untouched.

Basically, check out of one, drop CVS directories, check into the
second, check out of the second, and when doing work with either
repository you specify which repo with the -D flag.  Coupled with
the -j (merge) flag you can accomplish most tasks.

That said, if the work was thought through and beneficial you may be
able to obtain a branch in postgresql cvs to work with.


Thu, 28 Feb 2002 08:56:36 -0500
"Rod Taylor" <rbt@zort.ca>
Re: Arch (was RE: Refactoring of command.c )