Hi Richard,
> 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? > In order to test Fossil, I essentially did the following: 1) created a folder for repositories (c:\fossil\repositories), and used fossil new to create a repo called test.fossil 2) went to the root of an existing Visual Studio project, and did a fossil open c:\fossil\repositories\test.fossil, saw the _FOSSIL_ file was created and 3) did fossil add . to add the existing files to the new repository At that point I saw all the debug detritus going into the repo, so I played with deleting and ignoring things. :) So anyway, that initial prep for an existing project has to be done with Git etc. as well. However at that point I wasn't sure if I have to prep each working session by opening the repo, working/committing, and then closing at the end. This guy http://ronperrella.blogspot.com/2012/12/fossil-first-steps.html says Fossil "doesn't like it" if the repository isn't open, and while he also mentions that there's little reason to close a repo, there's also little reason to think he must know what he's talking about since that information isn't on the official site, hence the question. > 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. > That fully answers the question, thanks. > > 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". ) > This is also good information, since it's not clear from a newbie perspective. > > 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. > Hmm. I would hate to rely on Windows then if there's a reasonable possibility of corruption that way. > > > >> 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. I'd be happy to do a Linux box if I had the option, but I probably don't. So it sounds like in a pure-Microsoft environment, the windows service option is preferred. Thanks again, Pete
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
