Greetings All, We're looking at using Fossil due to its support for ticketing (among other things), and I'm the designated point man to figure it all out and teach the rest of the lazy SOBs -- I mean developer team -- how it all works. :) Looks like a very nice bit of work, from what I've seen so far. ;) I confess that the "up and running in 5 minutes" tutorial took me considerably longer since I'm on Windows and had to work a few things out that weren't crystal clear. Perhaps incorporating some lessons learned into the "5 minute" intro might save other Windows users some time.
First thing I wanted to was convert the .gitignore file I use with Visual Studio to Fossil's format. This is a typical one: https://github.com/github/gitignore/blob/master/VisualStudio.gitignore Since I don't think glob format includes a comment symbol, I just ran things together like so: *.suo *.user *.sln.docstates */[Bb]in/ */[Oo]bj/ *_i.c *_p.c *.ilk etc. That seems to work even without putting trailing asterisks on folders, e.g. */[Bb]in/*. Then you run into Windows quirks, such as the fact that you can't create a folder starting with a . from within the Explorer GUI, so creating a .fossil-settings folder at the project root and then a .ignore-glob file in that has to be done via the command line. So far so good. But then I decided I wanted to globally set crnl-glob to "*" to avoid having to type --no-warnings at every check-in, but following what I could find online only resulted in Fossil telling me I was being a knucklehead by repeatedly responding with the usage hint. It turns out that an asterisk in single quotes does the trick on Windows, i.e. fossil settings crnl-glob '*' --global. FWIW. 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. 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? 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. 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(?). 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, Pete
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
