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
