Am 22.05.2012 00:53, schrieb 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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Hi Colin,
I'm afraid I didn't completely get this.
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?
But isn't that similar to having a file lock strategy?
I'd be grateful for some more hints/explanations.
Best
Urs
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
