On Thu, 08 Aug 2013 23:12:52 +0200, Stephan Beal <[email protected]>
wrote:
On Thu, Aug 8, 2013 at 10:48 PM, j. van den hoff
<[email protected]>wrote:
2.
I'm not comfortable with categorically recommending to new users to
separate the database from the checkout. I know that many on this list
think this to be a good thing but in general
In fossil keeping them in the same dir can and does lead to user error.
Here's a concrete example which i've done more than once while doing
old-school refactoring:
perl -i -pe 's|func_name|new_name|g' *
fossil commit -m ...
fatal: not a checkout
???
Oops - i just filtered through my _FOSSIL_, corrupting it. The same is
even
easier to do on a repo db because they will match "safer" wildcards like
*.*.
yes, that can happen. but
nobody prevents the user from messing up the database irrespective of its
location I would say. and in-place stream editing of
files without taking care (`processing_everyting *' ...) sure is the
user's fault in the end. the "trivial" protection is to use
hidden/ dotted files (.fslrepo in my case would be an example).
(i've done that on SVN repos several times, too, when using find(1) in
conjunction with perl.)
but what does this proof? the next guy might be a tidy up fanatic and
accidentally remove the directory with all the repository files, right?
Yes, silly me - it's my fault, not fossil's. But now that i've done that
more than once i know better than to keep my repo and checkout together,
and i wholeheartedly convey that advice to you :).
that's appreciated but I won't take it (for now, at least ;-)), since I'm
quite happy with the state of affairs right now and tend
tend to be over-careful when starting stream-editing with wildcard lists.
and of course I presume that there _is_ some remote repository
which is in sync with my local one so that I'm on the save side anyway
(the whole point of using a DVCS, is it?)
so overall I am of the opinion to make this a choice of the prospective
new user instead of a sacrosanct "best practice" recommendation.
i _strongly_ recommend against keeping the repo db in the same dir as a
checkout. Very little can go wrong when they're separated and lots can go
wrong when they're not.
shall I invent a few things which _can_ go wrong when collecting all repos
in a common directory ? ;-)
I mean: the mailing lists of git, hg, bzr, svn, ... sure are not that full
of posts "I messed up my repository", at least not where
the 'messed up' is caused by the missing separation of repo and checkout.
this (the question where to put the repository file) is another example
where I don't quite understand why such a small thing (in my view anyway)
causes such strong feelings. I still believe: "let the new user decide
this himself, but don't strongly recommend one strategy over the other".
at least specifically point out where it really can make a difference
(multiple checkouts from the same db, maybe?)
For CGI/server modes, there's a related point: the dir containing the
repo
must be writable by the CGI/server process, and it's often possible (and
always preferable, from a security point of view) to place the db outside
of the webroot, in a dir owned by the CGI user (the account holder, for
most providers). This keeps the repo from being inadvertently directly
downloaded (as opposed to cloned, which has fewer security concerns).
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
