Dear Urs,
> It's astonishing - like reading a good book, but one written with my
> specific questions in mind :-)
:-)
> What I will have to see in action before really being able to believe it
> works in 'real life' is the merging of text files that have been changed
> by more than one person. Of course it's clear that it _must_ work
> (everything what I might have in mind with such a system is of
> magnitudes smaller than any average software project). But it's just
> hard to imagine ;-)
Here is what the program does (more or less):
It compares your version of the text with your starting point version.
Comparision is (usually) done line by line. Lines that are identical will
be left as they are. When it stumbles over the first difference, it looks
ahead in both files: Has this line been added? Have lines been removed?
Where is the next line that is in both files?
When it has the next common line, it looks at the two blocks between the
last common line and the next common line. It takes notes what has to be
done to get from your starting point version to your current version.
Now the program looks back in your and the official version's history. What
is the last version that both (your current version and the official
version) have as ancestor?
>From that ancestor, it computes the steps that have to be done to get your
current version (now in one step), the same it computes for the changes
that have been made official after your starting point.
Now it has two sets of instructions of the form "remove line number x",
"add lines ... after line number y". Both sets are straight forward,
without contradictions.
It now tries to combine those two sets of instructions into one set of
instructions. This will work without a glitch as long as the changes
occured on different lines. Only if there are changes on both sides in the
same line, then the program cannot know which version to take and will mark
those as 'problematic' for human review.
It is like caring for a garden. If you tell your boy to tend the lattice
and your girl to tend the flowers, both can work in the same garden
simultaneously without interference. Only if they both are to tend the
flowers, they might interfere, one removing what the other just planted.
Btw, I read up on git yesterday. By that I reallized that some of the
slight controversy in our posts stems from using different tools. So here
I'll try to re-describe the strategy I described with subversion terms with
words a git user might use. It might help others in this jungle of
technical terms...
With git, you can commit your changes as often as you want, as a commit is
a local action. This means maybe your committed stuff need not yet be ready
to be distributed. As your co-workers won't have to deal with these
intermittent states, this won't give problems to them. There is even no
need for an explicit branch, you just work locally.
When you are done with your portion of work and all is in an acceptable
state again, then you can pull what others did change in the mean time from
a "master repository". This master repository is just another git
repository for the project (a so-called clone). The only thing making it
"master" is your usage of this repository. Again check whether with this
update your stuff is still in acceptable shape. If so, push to the master
repository. This will publish your changes for your co-workers.
If all your co-workers work with their local copies of the repository, pull
other's changes from the master, and push their finished changes to the
master, then you are following exactly the same strategy that I described
with this branching stuff.
The master repository then is where the final version of the book will be
created, or from which you would create automated "daily builds".
If you do good testing after your pull, then there is no need for any kind
of locks. The program does all the locking by not allowing a push if
there's been an intermittent change you did not yet incorporate. Just make
sure you do not force it to commit/push in such a case ;-)
Hope that helps,
Susan
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
