Re: PostgreSQL Developer meeting minutes up

* Markus Wanner <markus(at)bluegap(dot)ch> [090602 10:23]:

> # Bang, you suddenly have 'testfile' and 'movedfile', go figure!
>
> I leave it as an exercise for the reader to try the same with a single
> historic origin of the file, as cvs2git does the conversion.

Sure, and we can all construct example where that move is both right and
wrong... But the point is that in PostgreSQL, (and that may be mainly
because we're using CVS), merges *aren't* something that happens.
Patches are written against HEAD (master) and then back-patched...

If you want to turn PostgreSQL devellopment on it's head, then we can
switch this around, so that patches are always done on the oldest
branch, and fixes always merged "forward"...

I'm not going to be the one that pushes that though ;-)

> I don't consider the above a "minimal confusion". And concerning
> humans... you get used to merge commits pretty quickly. I for one am
> more confused by a linear history which in fact is not.

But the fact is, everyone using CVS wants a "linear history"..... All
they care about is "cvs update...wait...cvs update ... time ... cvs
update ..."... Everything *was* linear to them. Any "merge" type things
certaily wasn't intentional in CVS...

> As mentioned before, I'd personally favor *all* of the back-ports to
> actually be merges of some sort, because that's what they effectively
> are. However, that also bring up the question of how we are going to do
> back-patches in the future with git.

Well, if people get comfortable with it, I expect that "backports" don't
happenen.. Bugs are fixed where they happen, and "merged" forward into
all affected "later development" based on the bugged area.

> As far as I know, it cannot be turned off. Use parsecvs if you want to
> get silly side effects later on in history. ;-)

Ya, that's one of the reasons I considered parsecvs the leading
candidate... And why I went thouth, and showed that with the exception
of the one REL_8_0_0 tip, it *was* and exact copy of the current CVS
repository (minus the 1 messed up tag in the repository).

> You consider it a mess, I consider it a better and more valid
> representation of the mess that CVS is.

So much better that it makes the history as useless as CVS... I think
one of the reasons people are wanting tomove from CVS to git is that it
makes things *better*... The "exact" history will *always* be
available, right in CVS if people need it. I thin the goal is to make
the "git" history as close to CVS as possible, such that it's useful. I
mean, if we want it to be a "more valid" representation, then really, we
should be doing every file change in a single commit, and "merging" that
file commit into the branch *every* *single* *time*... I don't think
anybody wants our conversion to be that much "better and move valid
representation of the mess that CVS is"...

It's a balance... We're moving because we want *better* tools and
access, not the same "mess that CVS is".

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.