Re: PostgreSQL Developer meeting minutes up

* Robert Haas <robertmhaas(at)gmail(dot)com> [090527 21:30]:

> > And actually looking at the history of the gpo repo, the branches are all
> > messed up with "merges" and stuff that I'm not sure where they are coming
> > from...  8.2, 8.3, and master(HEAD) are all the same as my gpo repo, but the
> > back branchs are very bad...
>
> This is really quite horrible. What is the best way forward here?

That depends entirely on what the project wants.

If you're just developing on HEAD with git to submit patches to official
CVS use, don't do anything... HEAD is in good state in both repos.

If you're using git to rebase patches and changes between branches, in
order to submit patches for official CVS use, use the PostgreSQL.git I
publish on repo.or.cz. It's back branches are in pretty good state too.

If the "project" wants to provide canonical "git" repository as a
cut-over from CVS, and CVS isn't going to be used anymore (other than
served as an anonymous "mirror" of the git repo by git cvsserver, or
have an old CVSROOT available as a public download for purely historical
inspection), then it's probably best to do a single CVS->git conversion
with one of the better tools (like parsecvs) that don't do incremental,
and publish a set of good "graft" point for those using gpo who want to
switch their current development onto the new git repo.

But, since git's a completely Dvcs at its core, and was built by people
thoroughly immersed in the tool-needs of vastly distributed VCS stuff,
no matter what the project deems the "official" git repository, people
will be able to continue to keep their current investment in git
development with stuff like grafts, filter-branch, rebase, etc.

a.

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