Re: PostgreSQL Developer meeting minutes up

Hi,

Quoting "Marko Kreen" <markokr@gmail.com>:
>>  I'm not sure whether we should mark the old branches getting merges
>>  down or the new branches getting merged up. I suspect I'm missing
>>  something but I don't see any reason one is better than the other.

As pointed out by others, it doesn't make sense to merge (all commits
since the last merge) from HEAD to the back branches. You'd have to
cherry-pick only the commits which actually have to get back patched.

The "new branches getting merged up" could work. That is, applying the
fix to the oldest back-branch which requires the fix first and then
merge it to all newer ones, including HEAD. However, that would
require some rethinking: instead of creating bugfix-patches for HEAD,
then manually adjust patches for back-branches and then group
committing, you'd have to create a bugfix-patch for the oldest branch
first, commit that and then merge that to the newer branches.

I consider merging a cleaner and simpler operation than
cherry-picking, because merging allows the VCS to keep track of what
needs to be propagated, while with cherry-picking, you'd have to keep
track of that manually (or with the help of other tools).

An example for that is the very same unability to properly track
renames when cherry-picking, just like what I explained for the CVS
conversion.

> It seems to require noticeable development effort to get a importer
> to a level it can do it.  Will this be a requirement for import?
> Or just a good thing to have?  Also how to check if all such merges
> are sensible?

If that's how you'd like to have the CVS repository represented in git
(which I'd support as well), I'd give it a try. With all of the work
I've done for mtn cvs_import I certainly have the necessary experience
in CVS conversion and with the cvs2svn algorithm itself.

> And note that such effort will affect only old imported history,
> it will not make easier to handle back-branch fixes in the future...

Hm.. depends, if you want to merge from older branches to newer ones,
instead of cherry-picking, it would certainly help to get the history
clean.

> Various scenarios with git cherry-pick and similar tools would still
> result in duplicate commits, so we would need a git log post-processor
> anyway if we want to somehow group them together for eg. weekly commit
> summary.  And such post-processor would work on old history too.

I think we should decide on either using merges or using duplicate
commits we try to link somehow. But then, we should IMO use that
scheme for the conversion as well as later on, so as not to get a
messy history, as you put it.

Regards

Markus Wanner