On Mon, 19 Jul 2010 06:00:36 -0700, Eric Kow <ko...@darcs.net> wrote:
So is this attempt to boil down your scenario accurate?
1. dev has rw on HEAD
2. dev has r on HEAD, release has rw STABLE
3. If I pull from HEAD to STABLE, then I will hard-link to a dev-rw
file (which defeats my ability to enforce dev-r on STABLE)
I think you meant to say "2. *release* has r on HEAD ...", but your #3
correctly describes one of the cases --nolinks tries to avoid. And if release adds a
step 4 to change everything in their repository to dev-r, it can now cause developers to
trip over issues because part of their rw repository became r-only.
>But the basic argument in the chat above is that (A) --nolinks does
>not work with hashed repositories
I hadn't known that... I would be much more alarmed if I was currently
using darcs in the environment that necessitated --nolinks. :-)
So with hashed repositories, the files that would be hard-linked are those
whose integrity can be verified with a hash... but if my boil-down of
q2007 is correct, then that doesn't make a difference from the standpoint
of making --nolinks useful.
Right. The --nolinks addresses a policy issue rather than a space-saving
issue. Although the latter is important most of the time, it's not always the
case.
As an aside, I'm a bit embarrassed to admit that I don't have a clear picture
what are the files Darcs tries to hard-link for old-fashioned repositories. It
appears that it can at least hard-link pristine (using changes in timestamps to
know when it has to remove the link and overwrite with a new file), but it does
not seem entirely reasonable for it to hard link patches.
At this point I don't recall either, but I ran into this issue "the hard way":
my attempts to setup separate dev and release repos with different permission sets for
different users were failing due to the hard links and --nolinks was the solution.
As was pointed out previously in this email chain it would be possible to write a script
that would convert all hard links back to separate file copies, but this would have (a)
failed the auditors because there would have been a window where the release repository
could have been affected, and (b) probably failed the VCS adoption committee because
"darcs is good but you have to write scripts to go through its repositories and make
changes after you do a darcs command" would be a really hard sell, given that none
of the VCS competitors would have this issue.
Well, as you can see, removing functionality is a decision we try not to take
lightly (hence the pressure to resist new functionality or at least ensure we
think real hard about it first).
So here's the course of action I think I'll go for
All good.
--
-KQ
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
