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