Hi,
On Tue, 7 Nov 2006, Han-Wen Nienhuys wrote:
> it's done. We don't have much of a policy for branches at the moment, but
> here's an overview of what we currently have
>
> - cvs-head : hourly sync of CVS HEAD
> - cvs-lilypond_2_8 : hourly sync of CVS lilypond_2_8
> - master : default branch for development.
>
> notes:
>
> * There are more branches, but they're currently unused.
>
> * don't push into CVS branches. This either breaks our sync cron job, or your
> changes will be discarded (I think the latter, but am not sure).
I think they will be discarded _when_ the file was changed in CVS, but I
am not totally sure. It could be that a conflict is introduced ("<<<<<")
and committed, which would be really bad.
If you want to make sure that nobody pushes into the cvs branches, you can
have a hook: if .git/hooks/update is executable, it will be executed
before updating. So, something like
-- snip --
#!/bin/sh
case "$1" in refs/heads/cvs*) exit 1;; esac
exit 0
-- snap --
should work. (This is untested, but I have a similar script preventing
simultaneous updates.)
> * if unsure of a change, just push into a new branch. With the last releases
> of GUB, it's easy to build from separate branches.
>
> Creating a new branch goes like
>
> git push git+ssh://repo.or.cz/srv/git/lilypond.git \
> my-branch:refs/heads/new-remote-branch
>
> Then you can push with
>
> git push git+ssh://repo.or.cz/srv/git/lilypond.git \
> my-branch:new-remote-branch
>
>
>
> I have two proposals for organizing branches, I hope Johannes (our resident
> GIT guru) will weigh in on what's best
>
>
> * have a debian-like: stable, unstable, exp
>
> where features start out in the exp branch, and go into unstable after
> initial testing. Every once in a while, we sync unstable to stable, and build
> a GUB release. We could have autobuild cron daemons that automate testing on
> unstable and exp, so we know when is a good time to sync.
>
> * have developer centered branches,
>
> master, master-hanwen, master-jan, master-eea, etc.
>
> and a build-meister who will pull in changes from different developers to
> synthesize a new release which will be the basis for the official GUB builds.
>
> Of course, this requires that we have someone who volunteers to be a
> build-meister. At present, master equals master-hanwen , and I'm the build
> meister. However, I wouldn't mind at all if someone else took over this job.
> All it requires is regular access to a fast linux running machine for running
> GUB.
>
>
>
> Johannes?
Sorry, I had to take some days off in order to stay sane. Got a nice tan
at the same time.
So, here is my take: it depends on the people, and what they want to do.
For example, if you want to try a super-cool feature, which will not be
finished in a couple of days, but more like a month, you should definitely
start a new branch. (You can merge/rebase with/onto master easily.)
However, if you want to interact a lot (which includes testing by
interested parties), you should stay Debian-ish.
Git does not limit you in any way here, you can even mix both approaches.
Having said that, in my experience it is easier to maintain the Debian-ish
development style, and only occasionally throw in a little side
development.
Ciao,
Dscho
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
