Re: Source management tools for lilypond projects

[Colin Hall]

Hi Urs,

In addition to version control your team may need the concept of a
build token.

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.

This discipline is particularly valuable as you approach a release
date.

Cheers,
Colin.

On Mon, May 21, 2012 at 11:13:54PM +0200, Urs Liska wrote:
> Dear Susan,
> 
> thank you for the valuable input.
> What you describe is basically what I thought how it works - but
> didn't know for sure due to lack of experience.
> Especially the aspect of branching is interesting, as I didn't
> really have an idea about that.
> So what you describe as the intention of your post is exactly what I
> needed ;-)
> 
> 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
> ;-) )
> 
> Best
> Urs
> 
> Am 21.05.2012 11:56, schrieb Susan Dittmar:
> >Dear Urs,
> >
> >I just have one thing to add to the discussion: *do* use one of the
> >repository tools! No matter which one (you had some suggestions already),
> >but do use one! I do so since about 10 years (csv originally, converted to
> >subversion some -- more than 6, I think -- years ago), and even for
> >personal projects on only one computer I would not want to go without that
> >any more. Now it's just a question whether I did check in often enough to
> >restore what I need restored, not how or whether to do it. And as soon as I
> >work on two computers (laptop and destop for example), it's a must have.
> >
> >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.
> >
> >To reduce problems with branch merging (adding changes of the main branch
> >to the work branch when someone else did a change), my next step would be
> >to forget about that work branch after having merged into the main branch,
> >and start a new branch for the next set of changes. Most newer repository
> >systems allow for a virtually endless number of branches.
> >
> >Maybe you know all that already :-). I just thought to describe this
> >strategy to you as a starting point for investigation, adding some of the
> >technical terms to help you getting used to them.
> >
> >Hope it helps and not just annoys,
> >
> >     Susan
> >
> >
> >_______________________________________________
> >lilypond-user mailing list
> >address@hidden
> >https://lists.gnu.org/mailman/listinfo/lilypond-user
> 
> 
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 

Colin Hall
South Mains
West Linton
EH46 7AY
Scotland

Tel: 01968 661994
Mob: 07786 677582