On Feb 22, 2006, at 5:28 AM, Matthias Fischmann wrote:
hi, I am trying to figure out a locking procedure for a repo containing mostly 5 tex files and shared by 5 people. I couldn't find any equivalent to 'svn lock', but relying on auto-conflict-resolution also seems a bad idea if the repository constists mainly of three to five latex files.
We used darcs for a paper recently with three authors. Reflecting on our experience, I would say in the ideal case I'd have a wiki which supported latex instead of wiki markup and generated HTML by default but also generated pdf files for download. The general impression that I got from using darcs (or any version control for authoring latex documents) is that it is very inefficient given the specialized domain of publishing. If I were forced to author more papers I would create a plugin for mediawiki for this type of authoring but fortunately I'm not often faced with this need.
When you're editing source code you may very well want a local copy of the code that diverges from the "official" version. Darcs really enables this with its distributed nature. Conflicts between versions is not detected until it is absolutely necessary that you deal with it. For things like open source development this is a win, plus it lets me work on a feature for a couple weeks before integrating my code with the work of others. It helps you have different releases of the same source code as well. When I've been an author on a paper we needed to centralize things and fight the divergence as much as possible. The way darcs works was fine for individual sections of the paper that belonged to a specific author but the common sections like the introduction were hard to share using darcs.
My idea was this: (1) If somebody starts working on a file, he broadcasts an e-mail to the project that this file is locked. Everybody complies. When the work is done, a 'free' message is broadcast, again via an e-mail read by all project members by hand. (2) If another person wants to work on a locked file, she can call the lock owner and neegotiate, probably resulting in (3) the file being split in two files and a fresh pair of locks being broadcast over e-mail, replacing the old one.
You could use posthooks to automatically broadcast messages when changes are applied to a central copy of the repo. I was going to suggest using tags as a form of lock but on second thought that's a bad idea. If you were really interested in exploiting current features of darcs you could use the 'test' with a script that checks for a lock file to see which files are locked and which user name wants to edit a given file and complains when a file is locked by a different user. You could do additional things such as setting a posthook to email everyone when a lock is added or removed from the lock file thus automating the broadcasts. It's possible that two people could edit the lock file and not get a conflict so probably what you'd want to do is list every file in the repository in the lock file and then on the same line as the file name specify if the file is locked or not. That way, whenever two people try to lock the same file a conflict will be generated. Of course this assumes your users will 1) edit the lock file, 2) record and push a patch containing just that editing of the lock file 3) work for a bit 4) record changes in several patches and record unlocking in a separate patch 5) push all patches.
This will probably do for this particular type of repo, but I was wondering whether anybody here has come up with better / other solutions?
Well, the process I just described might give you a way to partially automate what you described. But as I think about it more I realize that what I describe could be a total pain. Your authors now have this special patch they have to send in that is used to synchronize each other. This isn't bad per se, but it requires that people will update their local copies whenever there are changes which means you'll need/want to automatically send out notices when the repo changes. I think this directly relates to the problem we had where the darcs model was inefficient for paper writing and a wiki would be much better.
It would be interesting to compare notes when you're done with the authoring of this paper and let us know how it goes and how you solve your problem.
Thanks, Jason _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
