On Thu, 08 Aug 2013 23:36:14 +0200, Stephan Beal <[email protected]>
wrote:
On Thu, Aug 8, 2013 at 11:31 PM, j. van den hoff
<[email protected]>wrote:
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?
My point is only that that type of goof-up happens much more often if the
files are in the same place. i can't remember the last time i
accidentally
deleted/corrupted something which lived in a directory above my current
working path, but i can remember a handful of times i've corrupted source
repos doing various things i shouldn't have been doing.
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?)
Presumably, but why risk it? It's simply a question of risk management
for
me. The risk of any loss (maybe just one or two unpushed commits or wiki
edits) drops to near 0 if the repo is outside of the source repo. It
rises
notably above 0 if they live together.
so overall I am of the opinion to make this a choice of the prospective
new user instead of a sacrosanct "best practice" recommendation.
It's not sacrosanct, but it is best practice.
for you - fine. but why for everybody?
shall I invent a few things which _can_ go wrong when collecting all
repos
in a common directory ? ;-)
i wasn't naming hypotheticals - these are things i've done myself and
seen
done via posts on this list.
these perceived (or actual) advantages can be stated and again: the (new)
user
might then decide whether he believes these to be relevant. my point here
is:
when I started using fossil (coming from `hg') I just presumed the
repository
needed to reside within the checkout. afterwards I found statements that
this
might lead to database corruption (caused by fossil not by some stream
edit...)
then I learned these (old) problems are sorted out. and so I stayed with
the
initial approach which did me no harm whatsoever so far.
your point seems to be that putting the database somewhere else reduces the
risk that the user will be messing with it. I cannot (and don't want to)
disprove this
but it is not relevant for me (I have other ways to mess things up, of
course ;-)).
so, I maintain, the message should be "do as you like, both solutions work
just fine,
but please be aware of the following
pros and cons" (and there are some pros for keeping things together, too).
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.
i can mess up git using its own commands - i don't need perl for that ;).
very good point!
regards,
joerg
--
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
