Not sure if this was already discussed (I've been following the thread somewhat loosely), but it seems to me that git makes it a whole lot easier to handle a "build token" by virtue of the repositories being decentralized.
I admit, I'm not an svn expert and it's quite likely there are some svn workflows I don't know about. As far as I know, a commit in svn goes straight to the central repository -- mistakes immediately become public mistakes. When the supercollider source repository switched to git, it took a while for me to understand how to use branches, merges and cherry-picks, but once I did, it really seems to me that the git approach is much better -- because you can correct mistaken commits before they ever go public. So, you would do your work in a private branch, and when the new stuff is ready to go public for other contributors, only then merge into the master branch (or cherry-pick). If there are conflicts with another person's work, "git mergetool" to fix them before committing to master. You still might have screwed something up, but you can "git reset" to roll back in time, fix things and recommit, all privately without touching the public repository. If somebody pushed new stuff to the master branch that you don't have, git won't let you push publicly: git pull --rebase, which gets the new stuff and moves your stuff to be last in the revision history. That may cause conflicts -- "git mergetool" again -- and you have the chance to retest before pushing. It's this interim state of "I moved my stuff to master but haven't pushed it publicly yet" that I think corresponds fairly closely to the idea of a build token. Git is really awesome. hjh _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
