On Mon, Jun 17, 2013 at 7:47 PM, Pete Rihaczek <prihac...@gmail.com> wrote:
> > Some questions: > > 1) Coming from using Mercurial and Git, I'm using to firing up Visual > Studio and getting to work without any source control prep. > Help me to understand: Are you starting a new project? If you are starting to work on an existing project, where did you get the files to work on if you didn't do the "source control prep" first? > If the Fossil repository isn't open at the root of my project (i.e. no > _FOSSIL_ file) and I then open it to commit changes I made while it was > closed, it will first prompt to overwrite the changed files. That makes > sense, and I can decline the overwrites and then commit, but it would seem > that the desired workflow would be to open the repository before starting > to work. I even found a blog entry that claims "Fossil doesn't like it" if > you don't do that. Is there any threat beyond perhaps accidentally > overwriting work? > If you want to start the "source control prep" after the fact, that fine. The only danger is file overwriting. Note also the --keep option to "fossil open" which avoids all file overwriting. But if you make changes to some version of code you got "out of band" and then try to check it into fossil - are you sure you are checking it into the right branch? Are you sure nobody else has changed it in the meantime. There are lots of reasons not to do it that way. Just open the checkout from fossil first, then start editing, and you will avoid lots of potential problems and complications. > Related to that, is it necessary to close the repository when you're done, > or is it OK to leave it "open" between sessions, reboots, etc.? I just > want to make sure I understand the workflow to recommend and why. > Leave sessions open. There is hardly ever a good reason to close them. Sitting here typing this, I cannot think of even one reason why you would ever want to run "fossil close". (You will notice, btw, that "fossil close" is not on the list of commonly used commands that appear when you type "fossil help". ) > > 2) I played with cloning a repository locally on the same drive, and > autosync worked as expected. But of course I don't want to host the master > repository for a project on my local drive, lest the drive fail. What would > be the preferred method for sharing multiple repositories using a shared > Windows fileserver? Simply throwing the files on a shared drive doesn't > seem right due to locking and contention issues(?). > A shared drive will work, in theory, assuming file locking works on the shared drive. (Network filesystems are notoriously buggy in that respect.) Performance won't be optimal, but will probably be good enough. > Would the preferred method be creating the Windows service to share a > number of .fossil repositories, and then people can clone and autosync to > the various URLs presented by the service? Thank you, > > My opinion of the preferred solution is to run Fossil from CGI on a Linux box. I'm guessing you aren't going to go for that solution, so my second choice would be to run Fossil as a windows service someplace. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
