Horton

Thread

  1. linked list rewrite

    Neil Conway <neilc@samurai.com> — 2004-03-23T10:00:14Z

    I'd like to wrap up the linked list rewrite, and get the code into CVS 
reasonably soon. If you're unfamiliar with the motivations for 
redesigning the linked list code, check the archives for previous 
discussions, such as:

     
http://www.mail-archive.com/pgsql-patches@postgresql.org/msg02204.html
     
http://www.mail-archive.com/pgsql-patches@postgresql.org/msg01320.html

The basic idea is to ditch the Lisp-style linked list representation 
(in which a "list" is merely a pointer to the head node), and adopt a 
new List struct like so:

typedef struct List
{
  	NodeTag		 type;	/* T_List, T_IntList, or T_OidList */
  	int			 length;
  	ListCell	*head;
  	ListCell	*tail;
} List;

This allows us to implement most of the important list operations 
(length, prepend, append and concatenation) with constant time 
complexity, and speed up some other operations (such as equality).

The known remaining issues that need to be addressed are:

(1) API naming

In the latest prototype implementation, I've adopted a completely new 
naming convention for the functions in the list API. The new API looks 
like:

List *list_append(List *list, void *datum);
List *list_prepend(List *list, void *datum);
List *list_conc(List *list1, List *list2);
bool list_member(List *list, void *datum);
List *list_remove(List *list, void *datum);
etc.

Function variants which operate on integer lists (type = T_IntList) 
have an "_int" suffix, whereas OID list functions use an "_oid" suffix. 
By default, list operations use structural equality (i.e. equal()) -- 
if a list function uses pointer equality to determine if two list 
elements are the same, it has the "_simple" suffix. And so on.

In contrast, the existing List API is a lot more inconsistent (IMHO). I 
elaborated on some of the deficiencies of the existing API naming 
scheme here:

     http://archives.postgresql.org/pgsql-patches/2004-01/msg00188.php

Tom objected to changing the names:

      http://archives.postgresql.org/pgsql-patches/2004-01/msg00186.php
      http://archives.postgresql.org/pgsql-patches/2004-01/msg00191.php

(I won't summarize Tom's cogent points here so as not to put words in 
his mouth; however, please read those posts.)

I think changing the list API names is a good idea for a few reasons. 
First and foremost, it improves the readability of the code and the 
consistency of the list API. Second, one objection to changing the API 
names is that it requires more changes to the rest of the tree. While 
that's indisputable, I think we'll realistically need to visit the vast 
majority of the List API call sites in order to implement the list 
rewrite anyway, so in the long run I don't think changing the API names 
will be that much extra work. Third, it has the benefit of cleanly and 
totally breaking existing code that uses the List API, so that we don't 
miss any List API call sites whose semantics have subtly changed (e.g. 
a switch of a particular function from structural equality to pointer 
equality).

So, would people prefer that we keep the old API names, or adopt the 
new naming conventions?

(2) Remaining implementation work

The code has drifted a fair bit underneath the latest list rewrite 
patch (which was incomplete anyway). It's unfortunately been a little 
while since I've looked at the patch, but I don't recall there being 
any showstopping problems that needed to be resolved --- it's just a 
matter of wrapping up remaining loose ends. I'm going to get started on 
this on today.

(3) Apply the work to CVS, and update the rest of the tree for the new 
API

The amount of integration work that needs to be done partially depends 
on the resolution to #1, but either way the list rewrite will require a 
lot of (relatively minor) changes scattered throughout the tree. What 
is the best way to land these changes in HEAD with minimal disturbance 
to other developers?

One possibility is to create a private CVS branch, implement any 
necessary changes throughout the source tree and test all those 
changes, and then merge the branch into HEAD once it is ready. This 
would still break outstanding patches, as Tom has pointed out, but it 
might reduce the disturbance to other developers. It doesn't really 
matter to me whether this is done or not (I can do my own revision 
control locally if there's a need for it), so speak up if you think 
this would be worth doing.

Another possibility is to create some wrapper macros / functions that 
would insulate the changes in the list API, so that we could make the 
changes incrementally. Not sure how viable this is.

That's about it. Does anyone know of anything else that will need to be 
tackled before we can merge the list rewrite?

Cheers,

Neil

  2. Re: linked list rewrite

    Sailesh Krishnamurthy <sailesh@cs.berkeley.edu> — 2004-03-23T16:39:21Z

    Re changing APIs or not.

I agree with Tom that an incremental change is easier. More
importantly, it is also easier to test your implementation.

Even if everybody agrees that the API should be changed, IMO a better
way would be to first use your implementation with the old API and go
through some thorough testing to make sure it is AOK. Once we are
certain (or as certain as we can be) about that, you can changeover to
the new API. This way, when bugs show up we won't be left wondering if
its because of the new API interacting with some hidden assumption at
the call-sites or if it is only the implementation. 

One step at a time seems safer to me.

I would think a new CVS branch would be the right way to merge your
stuff especially if you are going with the API change route. That way
you won't have to lock the tip and can incrementally work with a
broken branch until it is fine (and keep re-merging).

Which brings me to another question .. has anybody considered using
subversion instead of CVS ? 

-- 
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh

  3. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-23T16:47:34Z

    Neil Conway <neilc@samurai.com> writes:
> The known remaining issues that need to be addressed are:
> (1) API naming

I'll keep my mouth shut about this one until some other people have had
a chance to weigh in...

> (3) Apply the work to CVS, and update the rest of the tree for the new 
> API

> The amount of integration work that needs to be done partially depends 
> on the resolution to #1, but either way the list rewrite will require a 
> lot of (relatively minor) changes scattered throughout the tree. What 
> is the best way to land these changes in HEAD with minimal disturbance 
> to other developers?

I'm not especially excited about the CVS-branch idea; I think that
you'll end up with a major merge headache, unless the branch lives for
such a short time that it'd hardly be worth doing anyway.  As I said
before, I'm willing to help out with the grunt-labor part of this so
that the change can be completed more swiftly.  If I'm doing that
instead of other stuff, that's one large source of code drift removed ;-)

What I would like to do is to set up compatibility macros along the
lines I suggested before, so that existing code will compile and work
as much as possible.  I am thinking that we'd actually leave the
compatibility macros in place indefinitely, but protected with a define
("#ifdef OLD_LIST_API" or some such).  This would make it easier for
people to deal with porting user-written code.  There are plenty of
scenarios where one would like a loadable module's source to compile
as-is against multiple backend versions, and that will be impossible
for anything that uses lists if we don't provide some hack like this.

The number of macros needed obviously depends on whether we rename
functions or not, but in any case the core of the thing would be
versions of lfirst, lnext, and foreach that cast their arguments so that
a pointer declared as List * can be misused as a list iteration variable.
There will be a small number of things that we cannot make work this
way, for instance applying lfirst to something that actually is a List
and not a ListCell, but I think we can make sure that all the commonly
used coding patterns work.

Given that, the work plan would look like this:

1. Finish up list.c and pg_list.h with compatibility macros; for the
   moment, #define OLD_LIST_API.

2. Debug until regression tests pass.  This will entail finding the
   places where the compatibility layer fails and fixing them.

3. Commit to CVS head.

4. Incrementally fix places that need API adjustment (locally turning
   off OLD_LIST_API should be sufficient to locate these).  Commit as
   the work is done, thereby avoiding any code drift problem.

5. Remove default definition of OLD_LIST_API.

			regards, tom lane

  4. Re: linked list rewrite

    Frank Wiles <frank@wiles.org> — 2004-03-23T16:53:10Z

    On Tue, 23 Mar 2004 08:39:21 -0800
Sailesh Krishnamurthy <sailesh@cs.berkeley.edu> wrote:

> Which brings me to another question .. has anybody considered using
> subversion instead of CVS ? 

  I for one would love to see more Open Source projects like PostgreSQL
  move to using subversion instead of CVS.  I've been using it for 
  awhile now on my little projects and it's a joy to work with. 

 ---------------------------------
   Frank Wiles <frank@wiles.org>
   http://frank.wiles.org
 ---------------------------------

  5. Re: linked list rewrite

    Dustin Sallings <dustin@spy.net> — 2004-03-23T17:18:11Z

    On Mar 23, 2004, at 8:39, Sailesh Krishnamurthy wrote:

> Which brings me to another question .. has anybody considered using
> subversion instead of CVS ?

	My guess would be only people who haven't used arch.  :)

	Seriously, though.  Decentralized, disconnected revision control is a 
lot nicer to work with in open source projects...especially larger ones 
with more developers in more locations.

-- 
Dustin Sallings

  6. Re: linked list rewrite

    Bruce Momjian <pgman@candle.pha.pa.us> — 2004-03-23T18:16:51Z

    Neil Conway wrote:
> (1) API naming
> 
> In the latest prototype implementation, I've adopted a completely new 
> naming convention for the functions in the list API. The new API looks 
> like:
> 
> List *list_append(List *list, void *datum);
> List *list_prepend(List *list, void *datum);
> List *list_conc(List *list1, List *list2);
> bool list_member(List *list, void *datum);
> List *list_remove(List *list, void *datum);
> etc.
> 
> Function variants which operate on integer lists (type = T_IntList) 
> have an "_int" suffix, whereas OID list functions use an "_oid" suffix. 
> By default, list operations use structural equality (i.e. equal()) -- 
> if a list function uses pointer equality to determine if two list 
> elements are the same, it has the "_simple" suffix. And so on.
> 
> In contrast, the existing List API is a lot more inconsistent (IMHO). I 
> elaborated on some of the deficiencies of the existing API naming 
> scheme here:
> 
>      http://archives.postgresql.org/pgsql-patches/2004-01/msg00188.php
> 
> Tom objected to changing the names:
> 
>       http://archives.postgresql.org/pgsql-patches/2004-01/msg00186.php
>       http://archives.postgresql.org/pgsql-patches/2004-01/msg00191.php

I agree a renaming of list functions is good.  If we had kept the
original Berkeley code as-is, we would have a lot fewer developers
today.  :-)  Making drastic cleanups is often worthwile.  I write
backend code and still can't remember which list function does what, so
clearer naming would help me a lot, and I am sure others too.

Tom had the idea of making compatible names for the old macros, and I
think that is an excellent compromise.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

  7. Re: linked list rewrite

    Alvaro Herrera <alvherre@dcc.uchile.cl> — 2004-03-23T19:04:15Z

    On Tue, Mar 23, 2004 at 05:00:14AM -0500, Neil Conway wrote:

[...]

> The basic idea is to ditch the Lisp-style linked list representation 
> (in which a "list" is merely a pointer to the head node), and adopt a 
> new List struct like so:

I assume you are doing away with the FastList hack too, aren't you?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
We take risks not to escape from life, but to prevent life escaping from us.

  8. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-23T19:45:36Z

    Dustin Sallings <dustin@spy.net> writes:
> On Mar 23, 2004, at 8:39, Sailesh Krishnamurthy wrote:
>> Which brings me to another question .. has anybody considered using
>> subversion instead of CVS ?

> 	My guess would be only people who haven't used arch.  :)

This reminds me quite a lot of a discussion that was just happening on
a Red Hat mailing list.  It seems the great thing about revision control
systems is there are so many to choose from ;-) ... and plenty of people
willing to proselytize for their favorite.

AFAICS, though, CVS is not broken for our needs.  I don't see an
adequate reason to change.

			regards, tom lane

  9. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-23T19:47:00Z

    Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> I assume you are doing away with the FastList hack too, aren't you?

Yup, we'll get to revert that junk too.

			regards, tom lane

  10. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-23T19:59:58Z

    Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Neil Conway wrote:
>> Tom objected to changing the names:

> I agree a renaming of list functions is good.  If we had kept the
> original Berkeley code as-is, we would have a lot fewer developers
> today.  :-)  Making drastic cleanups is often worthwile.

I would be satisfied if we kept the names of the core,
most-commonly-used functions the same.  I would put lfirst, lnext,
lcons, lappend, length, maybe member into the category of names
I don't want to change.  Attaching "_int" and "_oid" to those for the
related functions is okay.

If we go in that direction then the common prefix would be just "l"
and not "list_", which seems a good idea to me on grounds of brevity.
Looking over Neil's proposal again, one of the things that bugged me
about it was that the function names were overly verbose.  That's okay
for stuff you don't see often, but the common list functions are *all
over* the backend.  You can't really claim that developers will be
unfamiliar with them.  Making those names longer won't buy us anything
except sooner onset of carpal tunnel syndrome.

			regards, tom lane

  11. Re: linked list rewrite

    Bruce Momjian <pgman@candle.pha.pa.us> — 2004-03-23T21:32:32Z

    Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Neil Conway wrote:
> >> Tom objected to changing the names:
> 
> > I agree a renaming of list functions is good.  If we had kept the
> > original Berkeley code as-is, we would have a lot fewer developers
> > today.  :-)  Making drastic cleanups is often worthwile.
> 
> I would be satisfied if we kept the names of the core,
> most-commonly-used functions the same.  I would put lfirst, lnext,
> lcons, lappend, length, maybe member into the category of names
> I don't want to change.  Attaching "_int" and "_oid" to those for the
> related functions is okay.
> 
> If we go in that direction then the common prefix would be just "l"
> and not "list_", which seems a good idea to me on grounds of brevity.
> Looking over Neil's proposal again, one of the things that bugged me
> about it was that the function names were overly verbose.  That's okay
> for stuff you don't see often, but the common list functions are *all
> over* the backend.  You can't really claim that developers will be
> unfamiliar with them.  Making those names longer won't buy us anything
> except sooner onset of carpal tunnel syndrome.

Agreed.  Sounds like a plan.

What does the 'n' stand for in ncons?  I also felt that lcons
(construct) and nconc(concat) were too similarly named.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

  12. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-23T21:59:45Z

    Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What does the 'n' stand for in ncons?  I also felt that lcons
> (construct) and nconc(concat) were too similarly named.

I think nconc is a direct copy from the Lisp original; whatever its
origins are, they're back in Lisp prehistory.  I don't mind renaming
that one ;-)

Let's see ... fleshing out this idea a bit, here's a rundown of all the
symbols in pg_list.h and suggested new names:

ListCell accessors:

lfirst		no change
lfirsti		lfirst_int
lfirsto		lfirst_oid
lnext		no change
foreach		no change

List accessors:

length		no change

lfirstcell	new function to get first cell, or NULL if none

lfirst		rewrite as lfirst(lfirstcell()) when applied to a List

lsecond, lthird, lfourth	not clear if worth keeping

llastnode	llastcell

llast		Perhaps rewrite as lfirst(llastcell()) instead of keeping

makeListN	list_makeN or possibly list_make_N
makeListiN	list_makeN_int or list_make_N_int
makeListoN	list_makeN_oid or list_make_N_oid

lcons		no change
lconsi		lcons_int
lconso		lcons_oid

lappend		no change
lappendi	lappend_int
lappendo	lappend_oid

nconc		list_concat
We might also need a function to attach some bare ListCells to a List

nth		list_nth
		list_nth_int
		list_nth_oid
Should add list_nth_int, list_nth_oid, even though there are no
corresponding functions at the moment

member		list_member
ptrMember	list_member_ptr
intMember	list_member_int
oidMember	list_member_oid

LispRemove	list_remove
lremove		list_remove_ptr
lremovei	list_remove_int
		list_remove_oid		add, though not currently used

ltruncate	list_truncate

set_union	list_union
set_ptrUnion	list_union_ptr
		list_union_int		not currently used
set_uniono	list_union_oid

set_difference	list_difference
set_ptrDifference  list_difference_ptr
		list_difference_int	not currently used
set_differenceo	list_difference_oid

equali and equalo become just calls on equal()

freeList	list_free  (frees only List, not pointed-to objects)

listCopy	list_copy  (shallow copy of List only)

A couple of notes here: I propose using the suffix "_ptr" for operations
that use pointer equality rather than equal().  Neil proposed "_simple"
but that seems less than clear to me --- which one is "simple" and which
isn't?  Also, for the "set" operations I have just "list_union" etc
where Neil proposed "list_set_union".

Neil proposed inventing "list_deep_copy" which as far as I can see is
entirely redundant with copyObject.  Similarly I can't see any value in
list_equal when equal() will do the trick.

			regards, tom lane

  13. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-23T23:08:32Z

    I wrote:
> Let's see ... fleshing out this idea a bit, here's a rundown of all the
> symbols in pg_list.h and suggested new names:

Sheesh ... I forgot that I intended to do s/list_/l/g on that.

Doing so brings up one problem, which is that the old version of
lremove() conflicts with the new naming convention (it should have
had a name mentioning "ptr").  In the attached I work around this
by using "ldelete" rather than "lremove" as the base name for these
functions, but I'm open to other ideas.

ListCell accessors:

lfirst		no change
lfirsti		lfirst_int
lfirsto		lfirst_oid
lnext		no change
foreach		no change

List accessors:

length		no change

lfirstcell	new function to get first cell, or NULL if none

lfirst		rewrite as lfirst(lfirstcell()) when applied to a List

lsecond, lthird, lfourth	not clear if worth keeping

llastnode	llastcell

llast		Perhaps rewrite as lfirst(llastcell()) instead of keeping

makeListN	lmakeN or possibly lmake_N
makeListiN	lmakeN_int or lmake_N_int
makeListoN	lmakeN_oid or lmake_N_oid

lcons		no change
lconsi		lcons_int
lconso		lcons_oid

lappend		no change
lappendi	lappend_int
lappendo	lappend_oid

nconc		lconcat
We might also need a function to attach some bare ListCells to a List

nth		lnth
		lnth_int
		lnth_oid
Should add lnth_int, lnth_oid, even though there are no
corresponding functions at the moment

member		lmember
ptrMember	lmember_ptr
intMember	lmember_int
oidMember	lmember_oid

LispRemove	ldelete
lremove		ldelete_ptr
lremovei	ldelete_int
		ldelete_oid		add, though not currently used

ltruncate	no change

set_union	lunion
set_ptrUnion	lunion_ptr
		lunion_int		not currently used
set_uniono	lunion_oid

set_difference	ldifference
set_ptrDifference  ldifference_ptr
		ldifference_int	not currently used
set_differenceo	ldifference_oid

equali and equalo become just calls on equal()

freeList	lfree  (frees only List, not pointed-to objects)

listCopy	lcopy  (shallow copy of List only)

			regards, tom lane

  14. Re: linked list rewrite

    Bruce Momjian <pgman@candle.pha.pa.us> — 2004-03-23T23:50:44Z

    Tom Lane wrote:
> lcons		no change
> lconsi		lcons_int
> lconso		lcons_oid
> 

Should these be lnew or something clearer than cons-truct?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

  15. Re: linked list rewrite

    Bruce Momjian <pgman@candle.pha.pa.us> — 2004-03-24T00:00:59Z

    Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > What does the 'n' stand for in ncons?  I also felt that lcons
> > (construct) and nconc(concat) were too similarly named.
> 
> I think nconc is a direct copy from the Lisp original; whatever its
> origins are, they're back in Lisp prehistory.  I don't mind renaming
> that one ;-)

I found out why it is called Nconc:
	
	The name comes from CommonLisp: 'conc' for 'concatenate', prefixed by
	the 'n' which signals a dangerous function modifying existing lists.
	(Think of as as n-for-nuke.)

from:

	http://www.muq.org/~cynbe/muq/mufref_437.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

  16. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-24T00:05:37Z

    Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> lcons		no change
>> lconsi		lcons_int
>> lconso		lcons_oid

> Should these be lnew or something clearer than cons-truct?

No, lcons is one of the names that I think we should stick with on
historical grounds.  It's widely used in the backend and it has the
right connotations for anyone who's ever used Lisp.  "lnew" conveys
nothing, certainly not the right thing (it doesn't make a new List,
only a new ListCell).

			regards, tom lane

  17. Re: linked list rewrite

    Neil Conway <neilc@samurai.com> — 2004-03-24T01:30:38Z

    On 23-Mar-04, at 7:05 PM, Tom Lane wrote:
> No, lcons is one of the names that I think we should stick with on
> historical grounds.  It's widely used in the backend and it has the
> right connotations for anyone who's ever used Lisp.

I think it has exactly the *wrong* connotations: the name suggests that 
it creates a new cons cell (along with the ensuing implications about 
performance and the internal implementation of the list), which is no 
longer the case.

How about lprepend()? That allows for some symmetric with lappend().

-Neil

  18. Re: linked list rewrite

    Bruce Momjian <pgman@candle.pha.pa.us> — 2004-03-24T02:28:59Z

    Neil Conway wrote:
> On 23-Mar-04, at 7:05 PM, Tom Lane wrote:
> > No, lcons is one of the names that I think we should stick with on
> > historical grounds.  It's widely used in the backend and it has the
> > right connotations for anyone who's ever used Lisp.
> 
> I think it has exactly the *wrong* connotations: the name suggests that 
> it creates a new cons cell (along with the ensuing implications about 
> performance and the internal implementation of the list), which is no 
> longer the case.
> 
> How about lprepend()? That allows for some symmetric with lappend().

Wow, I like that one!

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

  19. subversion vs cvs (Was: Re: linked list rewrite)

    Marc G. Fournier <scrappy@postgresql.org> — 2004-03-24T03:03:03Z

    On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:

> Which brings me to another question .. has anybody considered using
> subversion instead of CVS ?

Why?  not that I'm for a chance from something that isn't broken, but what
advantages does subversion give us over what we already have?

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

  20. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-24T03:31:30Z

    Neil Conway <neilc@samurai.com> writes:
> On 23-Mar-04, at 7:05 PM, Tom Lane wrote:
>> No, lcons is one of the names that I think we should stick with on
>> historical grounds.  It's widely used in the backend and it has the
>> right connotations for anyone who's ever used Lisp.

> I think it has exactly the *wrong* connotations: the name suggests that 
> it creates a new cons cell (along with the ensuing implications about 
> performance and the internal implementation of the list), which is no 
> longer the case.

How do you mean it's no longer the case?  ListCell looks exactly like a
cons cell to me.

			regards, tom lane

  21. Re: subversion vs cvs

    Sailesh Krishnamurthy <sailesh@cs.berkeley.edu> — 2004-03-24T04:26:10Z

    >>>>> "Marc" == Marc G Fournier <scrappy@postgresql.org> writes:

    Marc> On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:
    >> Which brings me to another question .. has anybody considered
    >> using subversion instead of CVS ?

    Marc> Why?  not that I'm for a chance from something that isn't
    Marc> broken, but what advantages does subversion give us over
    Marc> what we already have?

I've had plenty of pain with cvs in terms of directories not being
first-class etc .. but I don't really contribute to pgsql so you guys
probably don't have the same experience. 

I was just curious as it looks like eventually subversion (or arch :-)
will be an alternative to cvs. 

-- 
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh

  22. Re: linked list rewrite

    Neil Conway <neilc@samurai.com> — 2004-03-24T05:37:49Z

    On 23-Mar-04, at 10:31 PM, Tom Lane wrote:
> How do you mean it's no longer the case?  ListCell looks exactly like a
> cons cell to me.

Sorry, thinko on my part. I meant to say that lcons() is a Lispy name, 
which suggests a Lispy implementation. This is no longer the case. 
While lcons() isn't that bad of a name, I think it is more confusing 
than it is helpful.

It just doesn't strike me that "construction" is a very useful way to 
talk about what this operation is actually doing, and is asymmetric 
with lappend() for no good reason. The operation is "prepending" an 
element to an existing list, so why not give it a name that reflects 
that?

-Neil

  23. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-24T06:10:20Z

    Neil Conway <neilc@samurai.com> writes:
> It just doesn't strike me that "construction" is a very useful way to 
> talk about what this operation is actually doing, and is asymmetric 
> with lappend() for no good reason. The operation is "prepending" an 
> element to an existing list, so why not give it a name that reflects 
> that?

Historic practice.  Sure, it's accident that lappend() is called what it
is, and it's accident that lcons() is called what it is, but there's not
adequate reason to rename either IMHO.  You might as well argue that
begin/end are asymmetric and we ought to use begin/nigeb.  (BTW I come
from a generation of programmers that actually did that sort of thing,
but fortunately the idea has mostly died out...)

Basically my argument is that we ought to preserve the well-entrenched
list function names.  I'm prepared to grant that, say, set_ptrDifference
is not well known and can be renamed at little cost.  I don't see the
cost-benefit argument for renaming lcons.  There are real cognitive
costs to changing commonly known names, and this surely qualifies as one.

			regards, tom lane

  24. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-24T06:36:56Z

    Neil Conway <neilc@samurai.com> writes:
> [ replace lcons with lprepend ]

BTW ... you may or may not consider this relevant, but "prepend" is not
a word, it's only a hackish neologism.  I can't find it at all in Random
House, and the Oxford English Dictionary lists it only as a "v. rare"
synonym for premeditate.  So I don't think there's much ground to argue
that it obviously conveys the right thing as compared to "cons".

			regards, tom lane

  25. Re: linked list rewrite

    Karel Zak <zakkr@zf.jcu.cz> — 2004-03-24T08:15:17Z

    On Tue, Mar 23, 2004 at 01:16:51PM -0500, Bruce Momjian wrote:
> I agree a renaming of list functions is good.  If we had kept the
> original Berkeley code as-is, we would have a lot fewer developers
> today.  :-)  Making drastic cleanups is often worthwile.  I write
> backend code and still can't remember which list function does what, so
> clearer naming would help me a lot, and I am sure others too.

 Maybe I already ask, is there any coding style recommendation for _new_
 written things?

 I agree  with Bruce. The list  functions and  a lot of  other functions
 can  be  candidates  for  rename. I  read  Mono  docs  last  night  and
 it's  perfect  if  they  can  write  to  docs  about  functions  names:
 "mono_<type>_<action>".

 I  think sometime  are people  too much  focus on  the shortest  way to
 target and forgot  that with code work others people  and not CPU only.
 (sorry of this pontification:-)

    Karel

-- 
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

  26. Re: linked list rewrite

    Dustin Sallings <dustin@spy.net> — 2004-03-24T08:28:42Z

    On Mar 23, 2004, at 11:45, Tom Lane wrote:

> AFAICS, though, CVS is not broken for our needs.  I don't see an
> adequate reason to change.

	Yes, of course.  I guess my point is that if you're going to move away 
from CVS, please don't just jump to ``slightly better CVS.''

	I'm looking forward to a world with more open source projects in 
distributed revision control.  The ones I'm tracking and doing personal 
branches against (vim, tla, a couple of other small projects) are 
liberating.

	Branching a tree I didn't expect to even have to edit while on an 
airplane recently was a very pleasant experience.  Actually, being able 
to branch without thinking about the horrible consequences of CVS has 
been wonderful in general.

	As long as CVS works for you, though, you should continue to use it.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

  27. Re: subversion vs cvs

    Chris Browne <cbbrowne@acm.org> — 2004-03-24T14:24:13Z

    After a long battle with technology, scrappy@postgresql.org ("Marc G. Fournier"), an earthling, wrote:
> On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:
>
>> Which brings me to another question .. has anybody considered using
>> subversion instead of CVS ?
>
> Why?  not that I'm for a chance from something that isn't broken, but what
> advantages does subversion give us over what we already have?

It's a newer design, offering some nice features:

- Directories, renames, and file meta-data are versioned.
- Commits are truly atomic.  (DB guys should like that :-).)
- Branching and tagging are cheap (constant time) operations
- Costs are proportional to change size, not data size
- Efficient handling of binary files
- Parseable output (one of the things better about SCCS than RCS/CVS)

Unfortunately, they have only just gotten to the point of having a
"stable" version.  Until very recently, different versions of
Subversion couldn't expect to talk to one another, which is a Very Bad
Thing.

In another year, it might be worth holding a debate over whether there
is value to considering Subversion or one of the Arch descendants as
an alternative to CVS.  I wouldn't think it's time yet.  And it would
be as wise to consider Arch as well; it has some pretty interesting
"repository" features...
-- 
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/multiplexor.html
"Those who doubt the importance  of  a convenient notation should  try
writing a LISP interpreter in COBOL  or doing long division with Roman
numerals." -- Hal Fulton

  28. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Frank Wiles <frank@wiles.org> — 2004-03-24T15:29:09Z

    On Tue, 23 Mar 2004 23:03:03 -0400 (AST)
"Marc G. Fournier" <scrappy@postgresql.org> wrote:

> On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:
> 
> > Which brings me to another question .. has anybody considered using
> > subversion instead of CVS ?
> 
> Why?  not that I'm for a chance from something that isn't broken, but
> what advantages does subversion give us over what we already have?

  Subversion has lots of "little" benefits, but nothing that would be
  a major incentive to switch.  The biggest benefits I can think of
  of the top of my head are: 

  * Commits are actually atomic 
  * protocol sends diffs in both directions which speeds up everything
  * branching and tagging are cheap constant time operations

  * the time it takes to make changes is based on the size of the
    change, not the size of the project

  * whole directories are versioned not just files.  So for example
    if you for some reason wanted to rename src/backend/bootstrap.c
    to src/backend/bootup.c you wouldn't lose your revision history
    information.  Same thing goes for complete reorganizations of the
    file layouts.  

  * You can checkout "parts" of a project so if you need to fix a
    bug in 7.3.6's src/backend/ you only have to transfer that portion
    to you.  

  * cvs diff ( well svn diff ) can be done offline.  Same with 'status'
    which shows you your local modifications and 'revert' which reverts
    your changes back to your last checkout/update/etc. 

  * Revisions numbers are repository wide instead of by file.  You can
    refer to revision #14328 on hackers and everyone knows exactly what
    you are talking about and can switch their working copies to it
    easily ( svn switch -r 14328 ).  It's sort of like having a tag
    for every commit made to the repository. 

  It does have some downsides that I have found, most notibly that the
  size of your sources you have in your working copy are essentially 
  doubled.  There is a copy in your .svn directory that allows the
  offline status, diff, and revert commands to work. 

 ---------------------------------
   Frank Wiles <frank@wiles.org>
   http://frank.wiles.org
 ---------------------------------

  29. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Dustin Sallings <dustin@spy.net> — 2004-03-24T18:09:08Z

    On Mar 24, 2004, at 7:29, Frank Wiles wrote:

> [cool feature list]

	Arch has all of that except for the checking out part of a directory 
thing  (would you really just check out the backend, submit a change, 
and not build and test it?).

	Additionally:

	* Repositories can be easily replicated so checkouts don't have to 
cross slow networks.  I replicate every repository I work with to every 
machine I use.  This is not only my backup strategy, but it makes 
checkouts faster.

	* You can work completely offline.  In addition to being able to diff, 
undo changes, redo changes, etc... while offline, you can completely 
branch a project do multiple commits, and merge them back into the main 
archive when your plane lands.

	* Branches are not only cheap, but can easily cross repository 
boundaries.  Any given user can create a branch from the head-of-line 
tree and maintain changes, and the head-of-line maintainers can pull 
those changes back in.

	* Its storage is immutable.  It never modifies a file so it does not 
provide any possibility for corruption.  This is also what makes 
replication so trivial.

	* Changesets have cryptographic checksums and may be cryptographically 
signed.  Checkouts are authenticated against both of these.

	* Repositories can be accessed via a wide variety of means.  Most of 
mine are local file, WebDAV, or SFTP.  I allow read-only access via 
plain HTTP for anyone who wants to check out one of my projects.

	* Files can be tracked in a nearly (or completely) automatic fashion.  
Depending on project configuration, you can avoid having to interact 
with the revision control system other than writing changelogs and 
submitting patches.  You an also use CVS-style tracking (manual adds 
and deletes (plus moves)) if you're more comfortable that way.

	* The design is way, way more simple and transparent, there are far 
fewer requirements.  At least for me, this translates to a higher 
confidence that my stuff will always be available.


	The advantage I see to Subversion is that it's designed to be a better 
CVS.  Since many people are comfortable with CVS and that style of 
centralized development, it may feel a little more natural for new 
converts.  I feel that that's because it doesn't seem to take you very 
far.

-- 
Dustin Sallings

  30. Re: subversion vs cvs

    David Garamond <lists@zara.6.isreserved.com> — 2004-03-24T19:40:41Z

    Sailesh Krishnamurthy wrote:
> I've had plenty of pain with cvs in terms of directories not being
> first-class etc .. but I don't really contribute to pgsql so you guys
> probably don't have the same experience. 
> 
> I was just curious as it looks like eventually subversion (or arch :-)
> will be an alternative to cvs. 

Eventually it (either subversion, or arch, or something else) will. You 
just have to be patient :-) The movement will be very slow, we'll 
probably see Apache 1.3.x disappear first before we see CVS disappear.

It _is_ frustrating to have to use something new, especially something 
so frequently used like source control tool.

-- 
dave

  31. Re: subversion vs cvs (Was: Re: linked list rewrite)

    David Garamond <lists@zara.6.isreserved.com> — 2004-03-24T19:45:26Z

    Frank Wiles wrote:
>>Why?  not that I'm for a chance from something that isn't broken, but
>>what advantages does subversion give us over what we already have?
> 
>   Subversion has lots of "little" benefits, but nothing that would be
>   a major incentive to switch.  The biggest benefits I can think of
>   of the top of my head are: 
> 
>   * Commits are actually atomic 
>   * protocol sends diffs in both directions which speeds up everything
>   * branching and tagging are cheap constant time operations
>   * the time it takes to make changes is based on the size of the
>     change, not the size of the project
>   * whole directories are versioned not just files.  So for example
>     if you for some reason wanted to rename src/backend/bootstrap.c
>     to src/backend/bootup.c you wouldn't lose your revision history
>     information.  Same thing goes for complete reorganizations of the
>     file layouts.  

Actually, the things you mentioned are pretty "major", as most of the 
above are really broken/painful to do/very slow in CVS. But, all of 
those probably will not motivate a seasoned CVS user enough to migrate.

So one might ask, what *will* motivate a die-hard CVS user? A real-close 
Bitkeeper clone? :-)

-- 
dave

  32. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Dustin Sallings <dustin@spy.net> — 2004-03-24T19:58:10Z

    On Mar 24, 2004, at 11:45, David Garamond wrote:

> So one might ask, what *will* motivate a die-hard CVS user? A 
> real-close Bitkeeper clone? :-)

	Since it's illegal for anyone who uses Bitkeeper's free license to 
contribute to another project, does anyone know if there are any 
features in Bitkeeper missing from arch (specifically tla) that matter 
to developers?  Or is there anything that may be a better match than 
arch?

	Unfortunately, I have never and will never use Bitkeeper unless 
someone buys me a license for some reason.  The distributed model seems 
like the only way to go for the open source development of the future.

-- 
Dustin Sallings

  33. Re: subversion vs cvs (Was: Re: linked list rewrite)

    David Garamond <lists@zara.6.isreserved.com> — 2004-03-24T21:22:52Z

    Dustin Sallings wrote:
> On Mar 24, 2004, at 11:45, David Garamond wrote:
> 
>> So one might ask, what *will* motivate a die-hard CVS user? A 
>> real-close Bitkeeper clone? :-)
> 
>     Since it's illegal for anyone who uses Bitkeeper's free license to 
> contribute to another project, does anyone know if there are any 
> features in Bitkeeper missing from arch (specifically tla) that matter 
> to developers?  Or is there anything that may be a better match than arch?

 From what I read here and there, BitKeeper excels primarily in merging 
(good merging is apparently a very complex and hard problem) and GUI stuffs.

>     Unfortunately, I have never and will never use Bitkeeper unless 
> someone buys me a license for some reason.  The distributed model seems 
> like the only way to go for the open source development of the future.

Not necessarily. For small to medium projects, a centralized model might 
work better.

-- 
dave

  34. Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

    David Garamond <lists@zara.6.isreserved.com> — 2004-03-24T21:33:49Z

    Andrew Dunstan wrote:
> (btw, if you want to work offline, which i saw referred to a couple of 
> times, wouldn't cvsup do most of the job?).

 From what I understand, a "distributed" source control means each 
developer gets his own _repository_, not just a working copy. This means 
you can commit to your own repo and even accept patches (either from the 
master repo, other developer's repo, or from a 3rd party). In Linux 
analogy, each developer can become an Alan Cox and maintain his own -ac 
line.

 From what I understand, CVSup is a tool to mirror the repository. It 
doesn't allow each copy of the repository gets independently developed, 
and then transferring around the modifications, or does it?

-- 
dave

  35. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Dustin Sallings <dustin@spy.net> — 2004-03-24T23:03:06Z

    On Mar 24, 2004, at 13:22, David Garamond wrote:

> From what I read here and there, BitKeeper excels primarily in merging 
> (good merging is apparently a very complex and hard problem) and GUI 
> stuffs.

	There's not a lot of GUI in arch, but star-merge is fairly incredible. 
  This is how tla (the main arch implementation) itself is developed.  
Lots of branches in lots of archives by lots of people.

>>     Unfortunately, I have never and will never use Bitkeeper unless 
>> someone buys me a license for some reason.  The distributed model 
>> seems like the only way to go for the open source development of the 
>> future.
>
> Not necessarily. For small to medium projects, a centralized model 
> might work better.

	I make use of the distributed nature of arch in my personal projects 
with no other developers.  Offline work is just a branch in another 
archive that gets merged in later.

	Arch supports a centralized model as well as anything else, and I've 
got a big centralized set of archives, but I don't always have good 
connectivity to the master.  This is where the distributed model wins.  
A server/network/whatever outage does not have the opportunity to slow 
me down.  In the worst case, a long outage causes my branch to drift a 
little further from head of line than it normally would.

-- 
Dustin Sallings

  36. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2004-03-25T02:02:34Z

    >   It does have some downsides that I have found, most notibly that the
>   size of your sources you have in your working copy are essentially 
>   doubled.  There is a copy in your .svn directory that allows the
>   offline status, diff, and revert commands to work. 

What's needed is a good window client like WinCVS, however...

Chris

  37. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Magnus Naeslund(t) <mag@fbab.net> — 2004-03-25T02:22:47Z

    Christopher Kings-Lynne wrote:
> 
> What's needed is a good window client like WinCVS, however...
> 
> Chris
> 

There is a number of those, our shop uses (and makes programs for) both 
windows and unix (and might soon use mac's aswell), so it's very 
important that there exists a good client for each. Especially if you 
version html pages and such that is edited by people that isn't so techy.

We're using TortoiseSvn right now, it's implemented as an explorer 
extension, so you just rightclick on a file or directory to 
update/commit/whatever.

What i like with svn is that it's a nobrainer for old cvs guys like me 
to use it. It solves all the problems with CVS right now, and promises 
more features later on (like much better than CVS merging).

The new buzz is distributed versioning systems these days, but i 
question if that is called for in the vast majority of projects out there.

If the only reason is for offline work that can be achieved with 
subversion too, with svk for example (haven't tried it, but been told 
that it works fine). Svk handles or will(?) handle distributed repos in 
the bk sense aswell, i believe.

But ofcourse arch has alot of features that are extremly cool, the 
reason why i didn't evaluate it further was that it didn't work on 
windows well, the fixed weird branching/version naming and the 
complexity of learning for our developers since they already use cvs.

Surely the two systems should be evaluated against their competiors 
within the same distribution models, not cross the boundries, since the 
  design is very different.

Subversions strength is it's percieved simplicity, and archs strength is 
it's complexity.

Regards,
Magnus

  38. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Dustin Sallings <dustin@spy.net> — 2004-03-25T03:44:05Z

    On Mar 24, 2004, at 18:22, Magnus Naeslund(t) wrote:

> The new buzz is distributed versioning systems these days, but i 
> question if that is called for in the vast majority of projects out 
> there.

	You can use distributed revision control systems as centralized 
systems, but not vice-versa.

> But ofcourse arch has alot of features that are extremly cool, the 
> reason why i didn't evaluate it further was that it didn't work on 
> windows well, the fixed weird branching/version naming and the 
> complexity of learning for our developers since they already use cvs.

	Depends on how you set it up.  In the recommended ``tagline'' method, 
you don't have to tell the revision control system when you add, 
remove, or move files (for the most part, binary files are not suitable 
for tagline).  All you have to do is commit and type a message.

> Subversions strength is it's percieved simplicity, and archs strength 
> is it's complexity.

	It is subversion's complexity that drove me away from it, in fact.

	Arch is incredibly simple all the way through.  It sounds like it must 
be complex to be able to do all of the things people do with it, but 
it's most assuredly not.  The requirements are few and basic (diff, 
patch, and tar).  The most common stuff is at least as simple as CVS 
(commit, update and in explicit mode, add, rm, and mv), and the 
advanced stuff is just as easy as the simple stuff (star-merge, tag 
(branching), etc...).

	As far as understanding the simplicity of arch (if you wanted to 
understand the problems it solves and implement it yourself), a really 
good presentation was posted today to the arch list that sums it up 
quickly and concisely.  It's hard to go through that and not think, ``I 
could write this.''

	http://web.verbum.org/tla/grokking-arch/grokking-arch.html

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

  39. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Matthew T. O'Connor <matthew@zeut.net> — 2004-03-25T04:13:40Z

    On Wednesday 24 March 2004 06:03 pm, Dustin Sallings wrote:
> 	There's not a lot of GUI in arch, but star-merge is fairly incredible.
>   This is how tla (the main arch implementation) itself is developed.
> Lots of branches in lots of archives by lots of people.

I would guess that better merging might be a real motivation for people.  If a 
patch that takes a month to develop can still apply cleanly despite 
significant code drift in the interrem, I could see that as a real motivating 
factor.


Matthew

  40. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-25T04:29:43Z

    "Matthew T. O'Connor" <matthew@zeut.net> writes:
> I would guess that better merging might be a real motivation for
> people.  If a patch that takes a month to develop can still apply
> cleanly despite significant code drift in the interrem, I could see
> that as a real motivating factor.

Not here.  You want me to trust some bit of code (with absolutely zero
understanding of the source text it's hacking on) to figure out how to
resolve conflicting patches?  That sounds like a recipe for big-time
unhappiness.

			regards, tom lane

  41. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Dustin Sallings <dustin@spy.net> — 2004-03-25T05:25:30Z

    On Mar 24, 2004, at 20:29, Tom Lane wrote:

> Not here.  You want me to trust some bit of code (with absolutely zero
> understanding of the source text it's hacking on) to figure out how to
> resolve conflicting patches?  That sounds like a recipe for big-time
> unhappiness.

	The idea is that it's the responsibility of the branch owner to keep 
it up-to-date.  For example, I've got a branch of tla (an arch 
implementation) I made soon after I started using it in order to add a 
command I wanted and refactor a bit of the insides.  Over time, a lot 
of stuff has changed, but I still want my stuff to work, so as I update 
my branch against head of line, I make minor changes to it as things 
go.

	The difference is that instead of having a patch sitting in a queue 
somewhere suffering from bit-rot, you've got a pointer to a branch that 
you can merge when you get around to it.  You can still view it as a 
diff if you want, but the diff you get six months after the original 
submission may be quite a bit different from what you would've got at 
the beginning if a lot of the code around it has changed.

	It's definitely not a magic tool that makes bad code good and 
conflicting patches happy.  It solves other problems, though.  Many of 
the problems you don't realize you have until you go back to something 
else and try to do something simple like undo all of the changes you've 
made since your last checkin.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

  42. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Neil Conway <neilc@samurai.com> — 2004-03-25T09:21:34Z

    On 25-Mar-04, at 12:25 AM, Dustin Sallings wrote:
> 	It's definitely not a magic tool that makes bad code good and 
> conflicting patches happy.  It solves other problems, though.

I don't think anything mentioned in this thread so far would be an 
enormous improvement over what we have now. However, I am still open to 
trying Arch or SVN: in the long run, I think the productivity gain from 
even an incremental improvement in the development toolset is worth a 
little effort in relearning and migration.

But as I said, I don't think it's a critical issue, and if other 
developers would rather we stick with what we have, that's fine with 
me.

WRT the relative merits of CVS, Arch, and SVN, David Wheeler (of 
Bricolage) has written an interesting article comparing the three 
systems:

     http://www.dwheeler.com/essays/scm.html

I think the lack of good Win32 support (unless rectified before the 
release of 7.5) is a pretty major problem with Arch -- that alone might 
be sufficient to prevent us from adopting it.

-Neil

  43. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Jan Wieck <janwieck@yahoo.com> — 2004-03-25T13:05:05Z

    Dustin Sallings wrote:

> On Mar 24, 2004, at 20:29, Tom Lane wrote:
> 
>> Not here.  You want me to trust some bit of code (with absolutely zero
>> understanding of the source text it's hacking on) to figure out how to
>> resolve conflicting patches?  That sounds like a recipe for big-time
>> unhappiness.
> 
> 	The idea is that it's the responsibility of the branch owner to keep 
> it up-to-date.  For example, I've got a branch of tla (an arch 
> implementation) I made soon after I started using it in order to add a 
> command I wanted and refactor a bit of the insides.  Over time, a lot 
> of stuff has changed, but I still want my stuff to work, so as I update 
> my branch against head of line, I make minor changes to it as things 
> go.
> 
> 	The difference is that instead of having a patch sitting in a queue 
> somewhere suffering from bit-rot, you've got a pointer to a branch that 
> you can merge when you get around to it.  You can still view it as a 
> diff if you want, but the diff you get six months after the original 
> submission may be quite a bit different from what you would've got at 
> the beginning if a lot of the code around it has changed.

The difference here is that instead of submitting a patch for review, 
which is then frozen, the branch owner can (and that means some will, no 
matter what your intentions are) keep modifying the branch during the 
review process, other than just keeping it in sync with conflicting 
changes to the trunk. How do you plan to prevent that?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

  44. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Alvaro Herrera <alvherre@dcc.uchile.cl> — 2004-03-25T13:49:17Z

    On Thu, Mar 25, 2004 at 08:05:05AM -0500, Jan Wieck wrote:

> The difference here is that instead of submitting a patch for review, 
> which is then frozen, the branch owner can (and that means some will, no 
> matter what your intentions are) keep modifying the branch during the 
> review process, other than just keeping it in sync with conflicting 
> changes to the trunk. How do you plan to prevent that?

I think it's much better for the reviewer to be able to see the history
of changes of the patch (branch), without having to look at the whole
patch again every time a small change is made to it.

Or do you diff two versions of a patch to see if the author only changed
what he says he changed?  Wow, a diff of a diff, _that_ should be
difficult to read.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Use it up, wear it out, make it do, or do without"

  45. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Andrew Dunstan <andrew@dunslane.net> — 2004-03-25T14:37:30Z

    Neil Conway said:

> I don't think anything mentioned in this thread so far would be an
> enormous improvement over what we have now. However, I am still open to
>  trying Arch or SVN: in the long run, I think the productivity gain
> from  even an incremental improvement in the development toolset is
> worth a  little effort in relearning and migration.
>

ISTM what we have here is a solution in search of a problem. When the
committers tell us that there is a problem we should start looking.


> But as I said, I don't think it's a critical issue, and if other
> developers would rather we stick with what we have, that's fine with
> me.
>

Maybe we should look at providing SVN as a project option on the new
PGFoundry. That might let at least a part of the community get its toes
wet with it, without disrupting the core in the first instance.

>
> I think the lack of good Win32 support (unless rectified before the
> release of 7.5) is a pretty major problem with Arch -- that alone might
>  be sufficient to prevent us from adopting it.
>

Agreed. It's a killer from my POV.

cheers

andrew

  46. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Magnus Naeslund(t) <mag@fbab.net> — 2004-03-25T17:22:45Z

    Dustin Sallings wrote:

 >
 >     You can use distributed revision control systems as centralized
 > systems, but not vice-versa.
 >

Not true, the other way around exists, that is what svk does.

 >     As far as understanding the simplicity of arch (if you wanted to
 > understand the problems it solves and implement it yourself), a really
 > good presentation was posted today to the arch list that sums it up
 > quickly and concisely.  It's hard to go through that and not think, ``I
 > could write this.''
 >
 >     http://web.verbum.org/tla/grokking-arch/grokking-arch.html
 >

Will read it, thanks.

Regards,
Magnus

  47. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Dustin Sallings <dustin@spy.net> — 2004-03-25T20:03:36Z

    On Mar 25, 2004, at 1:21, Neil Conway wrote:

> I think the lack of good Win32 support (unless rectified before the 
> release of 7.5) is a pretty major problem with Arch -- that alone 
> might be sufficient to prevent us from adopting it.

	I don't do Windows, but my understanding is that tla is as well 
supported on Windows as postgres is.

	The design is fundamentally easy enough that a Windows user who cares 
could probably make a more suitable port for Windows than the UNIX guys 
are interested in making.  I've seen such discussions on the list.

-- 
Dustin Sallings

  48. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Dustin Sallings <dustin@spy.net> — 2004-03-25T20:05:19Z

    On Mar 25, 2004, at 5:05, Jan Wieck wrote:

> The difference here is that instead of submitting a patch for review, 
> which is then frozen, the branch owner can (and that means some will, 
> no matter what your intentions are) keep modifying the branch during 
> the review process, other than just keeping it in sync with 
> conflicting changes to the trunk. How do you plan to prevent that?

	You do both.  Changesets are immutable.  A patch cannot be modified.  
However, new patches can be added for tracking changes to the tree.  
You can review the original diff, and you can review how it's tracked 
head-of-line changes independently.  You can take the original diff and 
manually wedge it in if you want, or you can see how the latest 
progress differs before submission.

-- 
Dustin Sallings

  49. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Dustin Sallings <dustin@spy.net> — 2004-03-25T20:07:23Z

    On Mar 25, 2004, at 9:22, Magnus Naeslund(t) wrote:

> >     You can use distributed revision control systems as centralized
> > systems, but not vice-versa.
> >
>
> Not true, the other way around exists, that is what svk does.

	From its description, svk sounds like a completely different system:

	``svk is a decentralized version control system written in Perl. It 
uses the subversion filesystem but provides some other powerful 
features.''

	I.e. it seems to have a CVS vs. RCS relationship.  It would be unfair 
to call CVS RCS.

-- 
Dustin Sallings

  50. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Thomas Swan <tswan@idigx.com> — 2004-03-25T21:01:05Z

    <quote who="Dustin Sallings">
>
> On Mar 25, 2004, at 1:21, Neil Conway wrote:
>
>> I think the lack of good Win32 support (unless rectified before the
>> release of 7.5) is a pretty major problem with Arch -- that alone
>> might be sufficient to prevent us from adopting it.
>
> 	I don't do Windows, but my understanding is that tla is as well
> supported on Windows as postgres is.
>

It that like the best beach volleball player in Antarctica?  The Windows
port of Postgresql is still in its infancy.  It's coming along, but its
not a finished product.


> 	The design is fundamentally easy enough that a Windows user who cares
> could probably make a more suitable port for Windows than the UNIX guys
> are interested in making.  I've seen such discussions on the list.
>
> --
> Dustin Sallings
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

  51. Re: subversion vs cvs (Was: Re: linked list rewrite)

    Neil Conway <neilc@samurai.com> — 2004-03-25T21:09:07Z

    On 25-Mar-04, at 3:03 PM, Dustin Sallings wrote:
> 	I don't do Windows, but my understanding is that tla is as well 
> supported on Windows as postgres is.

David Wheeler disagrees:

A serious weakness of arch is that it doesn't work well on 
Windows-based systems, and it's not clear if that will ever change. 
There are ports of arch, both non-native (Cygwin and Services for Unix) 
and a native port too. However, the current win32 port is only in its 
early stages, and the Win32 page on the Arch wiki says "Arch was never 
intended to run on a non-POSIX system. Don't expect to have a full 
blown arch on your Microsoft computer." At least part of the problem is 
the long filenames used internally by arch; arch could certainly be 
modified to help, though there doesn't seem to be much movement in that 
direction. Other problematic areas include symbolic links, proper file 
permissions, and newline problems, as well as the general immaturity of 
the port as of March 2004. Some people don't think that poor Windows 
support is a problem; to me (and others!), that's a serious problem. 
Even if you don't use any Microsoft Windows systems, people don't want 
to use many different SCM systems, so if one can handle many 
environments and the other can't, people will use the one that can 
handle more environments. I think GNU Arch's use will be hampered by 
this lack of support as long as this is true, even for people who never 
use Windows; good native Windows support is very important for an SCM 
tool.

-Neil

  52. Re: linked list rewrite

    Neil Conway <neilc@samurai.com> — 2004-04-26T03:50:09Z

    (To resurrect an old thread, I've finally got some time to devote to 
this; I'll post a patch once I've got something ready for public 
consumption.)

On 23-Mar-04, at 4:59 PM, Tom Lane wrote:
> Let's see ... fleshing out this idea a bit, here's a rundown of all the
> symbols in pg_list.h and suggested new names: [...]

Most of your suggestions are agreeable; a few minor quibbles follow.

> lfirstcell	new function to get first cell, or NULL if none
[...]
> llastnode	llastcell

What do you think of list_head() and list_tail() instead?

> set_union	list_union
> set_ptrUnion	list_union_ptr
> 		list_union_int		not currently used
> set_uniono	list_union_oid

I don't see the need for anything more than set_difference() and 
set_difference_ptr() -- if we're passed a T_IntList or a T_OidList, we 
can examine the list tag and do the Right Thing automagically. ISTM we 
only need the xxx_int() and xxx_oid() variants when something in the 
function's signature depends on the type of the list's elements.

> set_difference	list_difference
> set_ptrDifference  list_difference_ptr
> 		list_difference_int	not currently used
> set_differenceo	list_difference_oid

Ibid.

-Neil

  53. Re: linked list rewrite

    Tom Lane <tgl@sss.pgh.pa.us> — 2004-04-28T02:07:00Z

    Neil Conway <neilc@samurai.com> writes:
> Most of your suggestions are agreeable; a few minor quibbles follow.

>> lfirstcell	new function to get first cell, or NULL if none
> [...]
>> llastnode	llastcell

> What do you think of list_head() and list_tail() instead?

No strong objection, though I thought it was a good idea to include
"cell" in the function names to suggest that what you are getting back
is just a cell and not a List.  Anyone else have a preference?

>> set_union	list_union
>> set_ptrUnion	list_union_ptr
>> list_union_int		not currently used
>> set_uniono	list_union_oid

> I don't see the need for anything more than set_difference() and 
> set_difference_ptr() -- if we're passed a T_IntList or a T_OidList, we 
> can examine the list tag and do the Right Thing automagically.

Well, we could, but AFAIK there are no situations where the caller
doesn't know exactly what he wants, and so a switch in the function body
is just a waste of cycles.  It is probable that these functions are slow
enough and seldom-used enough that the extra switch doesn't matter much,
so that argument may not have much force.  I guess the real question in
my mind is whether there is any true gain in symmetry or readability by
doing it this way.  The other functions such as the cons family *will*
need to have the three variants, and so I question that it makes sense
to make these different.  Also the need for the _ptr variant makes it a
bit asymmetric even just when looking at these functions.

			regards, tom lane

  54. Re: linked list rewrite

    Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-28T04:12:21Z

    Tom Lane wrote:
> Neil Conway <neilc@samurai.com> writes:
> > Most of your suggestions are agreeable; a few minor quibbles follow.
> 
> >> lfirstcell	new function to get first cell, or NULL if none
> > [...]
> >> llastnode	llastcell
> 
> > What do you think of list_head() and list_tail() instead?
> 
> No strong objection, though I thought it was a good idea to include
> "cell" in the function names to suggest that what you are getting back
> is just a cell and not a List.  Anyone else have a preference?

I never liked "cell" myself.  It is too vague to me.  But I see your
point that list_head you would think returns the head of the list, not
the first element in the list.  Maybe list_first and list_last?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

  55. Re: linked list rewrite

    Neil Conway <neilc@samurai.com> — 2004-04-28T23:22:10Z

    On 28-Apr-04, at 12:12 AM, Bruce Momjian wrote:
> I never liked "cell" myself.  It is too vague to me.  But I see your
> point that list_head you would think returns the head of the list, not
> the first element in the list.

I'm not sure what you mean: list_head() returns the "head of the list", 
which is the first cell in the list. That cell contains a data value 
and a pointer to the next cell in the list. Makes sense to me...

-Neil

  56. Re: linked list rewrite

    Neil Conway <neilc@samurai.com> — 2004-04-28T23:29:09Z

    On 27-Apr-04, at 10:07 PM, Tom Lane wrote:
[ ... on the topic of list_union(), list_union_int() and friends ]
> I guess the real question in my mind is whether there is any true gain 
> in symmetry or readability by doing it this way.

I think there's a small gain: everything else being equal, an API with 
fewer functions is easier to use and easier to understand. If we can 
provide a single function that takes the place of three functions 
without losing anything, we ought to do so.

-Neil

  57. Re: linked list rewrite

    Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-29T04:31:22Z

    Neil Conway wrote:
> On 28-Apr-04, at 12:12 AM, Bruce Momjian wrote:
> > I never liked "cell" myself.  It is too vague to me.  But I see your
> > point that list_head you would think returns the head of the list, not
> > the first element in the list.
> 
> I'm not sure what you mean: list_head() returns the "head of the list", 
> which is the first cell in the list. That cell contains a data value 
> and a pointer to the next cell in the list. Makes sense to me...

Oh, I thought cell returned the first data value, not the
first-data-and-pointer-to-next-one.  Yes, list_head and list_tail seems
fine.  Why mix "cell" in there?  I don't know what a cell is.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073