Re: Source management tools for lilypond projects

[Colin Hall]

Hi Urs,

On Tue, May 22, 2012 at 01:42:14AM +0200, Urs Liska wrote:
> Am 22.05.2012 00:53, schrieb Colin Hall:
> >On Mon, May 21, 2012 at 11:13:54PM +0200, Urs Liska wrote:
> >>In the meantime I had already decided to go this way for the next
> >>projects. Our current project that we organize with a shared Dropbox
> >>folder starts to become more and more complicated with regards to
> >>keeping everything in sync (although it is _far_ better than having
> >>independent copies of the folder structure and exchanging everything
> >>by email (not to speak about Floppy Disks, which would of course
> >>take way too long to be always sent from Germany to Poland and back
> >>;-) )

The above paragraph indicated to me that integration of your team's
work has been a problem in the past.

If that is not the case then build tokens and integration are probably
not a concern for you, and my comment was irrelevant.

Susan gave a great explanation on "commit often" and the more of that
you do, the less you will need to manage integration:

> >>>One thing you will have to think about is check-in policy though. I
> >>>personally like to check in very often, but that means the checked in
> >>>version might not compile, let alone be in a state acceptable to use.
> >>>I guess for truely collaborative work you will want to reduce official
> >>>check-ins to working versions. This can be combined with my "check in
> >>>often" wish by using branches: Work in your personal branch (and check in
> >>>there as often as you want) until you are content with the results, and
> >>>when an acceptable state of your work has been reached (compiles fine, and
> >>>conforms to all the criterions you defined for an official checkin), merge
> >>>your changes back to the main branch.

And then she mentioned what I know as "integration":

> >>>To reduce problems with branch merging (adding changes of the main branch
> >>>to the work branch when someone else did a change)

If the above step is causing you unmanaged delays, the build token
idea can be helpful.

Version control does not address this issue. After version control you
are still left with the "does my stuff work with your stuff"
problem. This is integration.

> >The person holding the token has the right to merge in their latest
> >work and, in so doing, break the project. They also have the
> >responsibility to leave it in a working state before releasing the
> >token for the next person.
> >
> >Leaving it in a working state can mean reverting to the previous
> >working version, something that is easy if you have version control in
> >place.
> 
> Does that 'token' mean that only one person at a time is allowed to
> merge their changes to the repository, while the others have to wait
> for their turn?

Yes. For the main branch only.

As Susan said elsewhere, each person can (and should) have lots of
branches of their own and develop freely within them.

> But isn't that similar to having a file lock strategy?

It is a concept of a lock, but instead of a file lock, it's more like
a product lock.

If you're interested by these ideas see [1].

Cheers,
Colin.

[1] http://martinfowler.com/articles/continuousIntegration.html

-- 

Colin Hall