Re: [fossil-users] A note and some questions multiple users and fossil
On 05/11/2010 07:40 AM, jim Schimpf wrote: This document repository is a very degenerate case since there is really only one file in work. With multiple users they are going to be editing the same file at the same time. I think breaking up a long document into chapters is a common practice. But even with one file, if you're working on different parts of the same document, you should be fine. Fossil should automatically merge non-conflicting changes. Of course, it's possible to have changes that conflict at the human meaning level without conflicting as far a program can tell. E.g., if someone reworks an earlier paragraph that you're trying to reference later. This problem is not unique to proper revision control systems--it happens any time people collaborate and on a document and can even happen when working all by oneself if the work is large enough and/or spread out over enough time. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A note and some questions multiple users and fossil
Thank you for the comment, yes in general Fossil handles this pretty well. Just there are difficulties at times when you have a text file that is marked up but is a structured file. I have to be particularly careful with XCode project files where the Fossil markup if present makes them un-readable to the IDE. The solution there is the use of revert then changing the old file to the new via the IDE. I did some experiments with using diff and patch to update some files to prevent forks and sometimes it worked. I guess you just have to look at the changes and if necessary use a text editor to get all the changes in then force a commit. If you understand the purpose of the changes then you will probably get it right. It just won't always be automatic. Most of my early work on SCM's was with a checkout type system where you don't have to think this way. I have to adjust my ideas of how to handle changes. --jim On 17 May, 2010, at 12:06, Joshua Paine wrote: On 05/11/2010 07:40 AM, jim Schimpf wrote: This document repository is a very degenerate case since there is really only one file in work. With multiple users they are going to be editing the same file at the same time. I think breaking up a long document into chapters is a common practice. But even with one file, if you're working on different parts of the same document, you should be fine. Fossil should automatically merge non-conflicting changes. Of course, it's possible to have changes that conflict at the human meaning level without conflicting as far a program can tell. E.g., if someone reworks an earlier paragraph that you're trying to reference later. This problem is not unique to proper revision control systems--it happens any time people collaborate and on a document and can even happen when working all by oneself if the work is large enough and/or spread out over enough time. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] A note and some questions multiple users and fossil
(1) I'm working on a Fossil for Dummies document. I would hope this would be useful to the group as it could be passed to a new user to get them started. It tries to answer the questions of someone just starting out in Fossil. The work can be found at: http://pandora.dyn-o-saur.com:8080/cgi-bin/Book.cgi/index You can download the PDF. It is NOT done, I wanted to let the group comment on it to see if I was going in the right direction. Also I set is up as a creative commons document and am open to other authors. (2) While working on the document, the chapter on multiple users brought up some questions. This document repository is a very degenerate case since there is really only one file in work. With multiple users they are going to be editing the same file at the same time. This gets into the merging, branching complications of Fossil. I show a way of handling it here, and while it works is there a better way ? With a larger repository (i.e. more files) this might be less of problem since different users work on different files. Should you for example, do a fossil update while you are working to ensure you are up to date. Oh yes on fossil update, when you run it with the -n option it does not access the network repository but only the local one. So running fossil update and fossil update -n give different results if the master has been updated. --jim schimpf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
