lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Source management tools for lilypond projects


From: Susan Dittmar
Subject: Re: Source management tools for lilypond projects
Date: Tue, 22 May 2012 12:22:52 +0200
User-agent: Mutt/1.5.9i

> If we'd use the 'build token' concept (be it through empty emails or 
> 'lock files') then we're basically where we are right now (with a shared 
> folder): tell the others which file I'm going to edit and ask them to 
> leave this alone for a while.

It looks similar, but there are big differences! You do not tell them to
leave the file alone, just to not finalize their changes with this file
yet.  Every one can continue to work on his part of the things even when
another does wear the master head at that moment. What you are telling by
"locking" is not "do not touch", but "do not update from that" and thus 
"do not finalize".

Let me try to explain.

Let's say, A and B are both working on one file. A works on the lyrics, B
works on the polyphony (just let's assume both are in the same file).

In his local copy, A can make as many changes as he wants, and all is fine.
In his local branch, he can even do as many checkins as he wants, still all
is fine.

At the same time, B an do as many changes to *the same* file locally as she
wants. In her local branch, she can do as many checkins as she wants, too.

Now A thinks all is fine with the lyrics. He now tells the group "I will do
an official checkin to the file now". From now on, *the main branch of the
file* is his to work on. He tells the repository program to merge his local
changes to the main stuff. As the main stuff is still the same as when he
created his local branch, all should work well. He does the necessary
consistency checks (like "compiles" and "looks well"), does (if necessary)
a final checkin to the main branch, then tells the group "file is free
again".

Remember, B was working on the same file. Even while A does his release and
locks the file, B gladly continues her work on the polyphony (and thus on
the very file A did lock!). Now, some time later, B finally is content with
the results and could check them in.

First she checks whether someone is holding a lock over the file. As A
already did his final commit, none does, so B can continue. She tells the
group (more on that later) that now she is wearing the master hat for that
file.

Next she tells the repository software to update *her local copy* with the
changes commited to the main trunk in the time between her checkout (the
moment she started to work on the file) and now.

This is the crucial point in which repository programs are such a help: A
and B did simultaneously *work* on the same file, and just the *checkin*
needs to be one after the other!

As A did change the file, the update will change B's copy. Usually, those
changes can be done by the repository software without problems. But if
A's changes and B's changes are too close together (like in the same line),
the software cannot tell which change will have to be kept, and will now
ask B about that.

After these clashes are solved, B has to do all the consistency checks
again. All was well with her changes before she did the update, but maybe
now she has do add some tweaks again.

B goes on making sure the file becomes consistent with policy ("compiles",
"looks well", ...) again.

Then B makes her final checkin, and gives back this file's rubber chicken
for the next one to grab.



How this rubber chicken mechanism is implemented depends on your group,
your requirements (what needs to work after a checkin?), and the software
you use. My approach with the branches would allow you to leave all the
locking and communication to the software. You create your branch at the
moment you start to work on a file, work within that branch until you think
all is well, update this branch from the main trunk to incorporate other's
changes, check integrity again (repeat update/check until there's only very
short time since last update), then commit your changes to the main trunk,
check consistency again to make sure (and correct immediately if needed),
and then forget about the branch afterwards. Only the time between your
committing to the main trunk and the moment you are sure consistency is
still obtained is time where others cannot be asured a newly checked out
version will work fine. This is the only time you might want to 'lock' a
file or even the whole thing.

For all this, no direct communication is necessary, just the discipline to
only make checkins to the main branch only when they do not break
consistency (and rather revert to previous main version and do the
corrections in your work branch than have the main version inconsistent).

Again, how this "main branch" and "work branch" thing is reallized depends
on preferences and the software used. I do not know git (yet), only
subversion (SVN), so I cannot compare.

Hope this helps,

        Susan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]