Re: Repo user

[Johannes Schindelin]

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