Some random comments on using fossil in a large team, keeping the .fossil
file inside the repository etc.
I saw the fossil autosync methodology as being a nice bridge to make DSCM
approachable and usable for developers familiar with svn or DesignSync. I
still think it has helped but the resistance to a cheap branch and merge
vs. file locking was much higher than I ever anticipated.
In my group we extensively use the "repo in the checkout" methodology but
we put the db in a .fossil dir so that by default it is not found. We
haven't had any problems. The fsl wrapper does the clone and open and the
net effect is a big savings in time and training.
I certainly see the potential merit in sharing fossil db's between
checkouts but the cost of not sharing seems small.
For one of our users to get a fossil repo (we have over 200 fossils to
manage) using the wrapper they do something like:
fsl repo get common megatest
Where "common" is an "area" and megatest is a fossil, i.e. megatest.fossil.
They then end up with:
common-|-.fossil-|-megatest.fossil
| _FOSSIL_
....
This part works great.
Probably the biggest annoyance has been the steady stream of complaints
about the behaviour of "rm" and "mv". The early stages of a project where
there are many changes to the directory structure are very painful. The fsl
wrapper fixes "mv" but I've yet to get around to completing the fix of
"rm". Another painful quirk is the fact that running fossil update will
bring back files that have been removed from the disk even if they are
marked as DELETED. You only get one shot to do undo. I now promote a
methodology of doing all your churn in your Unix dirs and then "fsl
addremove" to bring the repo in sync and I'm much more cautious with the
"update often" mantra.
I tested performance quite heavily, hundreds of thousands of checkins,
files hundreds of megs in size etc. and was quite satisfied. There have
been no complaints about this that couldn't be fairly attributed to slow
file servers or similar external factors.
Syncing fossils between remote sites has been more challenging than it
should have been. The ssh transport does not work for us (ssh itself was
fixed but there is some interaction with tcsh that breaks it) and so we
sync all the fossil files between sites. Our data is sensitive and we
cannot expose ports serving http so we do a round-robin of rsync over ssh
and file-to-file fossil sync to keep the sites in sync. The delay is
typically 2 minutes for all two hundred plus fossils and so forks can
easily happen. Although it takes only 20 seconds to fix most forks a lot of
people find them intimidating or confusing. This is essentially a training
issue.
I hope this summary is of some use. The wrapper we use is here:
https://chiselapp.com/user/kiatoa/repository/fsl/home
On Tue, Dec 18, 2012 at 4:28 PM, j. v. d. hoff <veedeeh...@googlemail.com>wrote:
> On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp <d...@sqlite.org> wrote:
>
> On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer <m...@mired.org> wrote:
>>
>> I don't do that (I keep all my fossil repositories in ~/repos), so
>>> haven't paid close attention to the issues. The big one seems to be
>>> accidentally trying to add the repository to itself. The resulting
>>> checkin never terminates. I also recall problems with Windows
>>> (something else I don't use) where the solution was to move the
>>> repository out of the work space.
>>>
>>> Maybe the people who helped solve the problems can comment on this? Or
>>> maybe my skimming of such problems has led me to a false conclusion.
>>>
>>>
>> I think all these problems are fixed and that it is safe to keep the repo
>> in the check-out directory.
>>
>
> relieved to here that, thanks. are there any other valid arguments (beyond
> matter of taste things like "I want to separate the repo from the checkout"
> and facilitating backups by putting all repos in a single place) which make
> it unwise to keep the repo within the checkout?
>
>
>
>>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> ______________________________**_________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.**org <fossil-users@lists.fossil-scm.org>
> http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users<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
