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. > > 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. > 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 ;). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
