[darcs-users] [patch304] Reduce DarcsFlag usage in Darcs.Patch and Darcs.Repository

Eric Kow kowey at darcs.net
Mon Jul 19 13:00:36 UTC 2010


On Sat, Jul 17, 2010 at 22:49:32 -0700, Kevin Quick wrote:
> I'm no longer using the --nolinks flag... unfortunately because
> another VCS was chosen by the selection committee for the environment
> in question (although I still personally use darcs extensively).  As
> such, it's removal wouldn't directly break things for me.

Thanks for the note.  I'll go ahead and push the patches now, but I've
sent another poll out as a sort of safeguard.

> That said, I do think it still serves an important purpose.  It's not
> common in the open-source world, but in the corporate world where
> there's much more rigid and controlled access to code in the "QA" and
> "Release" domains (especially ISO-9001 organizations) the issues of
> permissions and stand-alone completeness overshadow issues like saving
> disk space.  It becomes more important to "lock down" QA and Release
> environments using permissions (and more) and hard-links are a
> back-door in that whole mechanism, and from the user perspective,
> "--nolinks" seems like an easy solution.

Permissions.  I still have a very hard time wrapping my head around
this, sorry.

Quoting you from four years ago:
q2007> The --nolinks is most useful for policy management.  As an example,
q2007> consider a project with a number of contributors but which has a single
q2007> release manager.  This project might have two principle repositories: a
q2007> "dev" repository and a "release" repository.
q2007> 
q2007> The dev repository has read and write access for all members of the
q2007> project group; any developer can push a patch into the dev repository.
q2007> 
q2007> The release repository is readable by all members of the project group,
q2007> but only writeable by the release manager.  That individual only pushes
q2007> vetted patches into the release repository.
q2007> 
q2007> In this dev/release scenario, if the patches exist on the same
q2007> machine/filesystem, a get/pull/push will usually result in hard-links
q2007> to the same file.  However, owner, group, and permissions for a
q2007> hard-linked file are global to all links, so it's impossible to have
q2007> different settings for patches shared by both repositories unless
q2007> --nolinks is used to ensure that each repository has its own copy of
q2007> the patch.

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)

> >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.

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.

> The eternal stress between forward progress and backward compatibility.
> There's no good answer to that and we don't want to be to cavalier about
> abandoning previously released functionality too hastily.  I'm trying to avoid
> coming across as Mr. Corporate here, but I can say that if we were using darcs
> in the originally targeted environment that even things such as abandoning old
> fashioned repositories wouldn't be a trivial upgrade.

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

1. Post one last poll to darcs-users:
     http://lists.osuosl.org/pipermail/darcs-users/2010-July/024538.html
   I'm using Nathan Gray as a representative user of old-fashioned
   repositories (in the event that nobody answers)

2. Apply patch304 now (which removes --nolinks and cleans other stuff up)

3. If Nathan or anybody else replies saying that they do use the feature
   then create a Darcs-2.5 ticket urgently so that we can revisit the
   question

> I suspect that you are primarily removing --nolinks because it extended the
> DarcsFlags tentacles and is therefore awkward to work with.  Refactoring and
> cleaning up code is one of my favorite things to do as well, but I would throw
> out the caution that the nolink flag doesn't seem to be a very radical flag (in
> either purpose or implementation requirements) so its very inconvenience in the
> implementation might be illuminating a design that is still suboptimal.

That's worth considering.  Seems like we're caught between global information
which makes things unpredictable and splatter.  Petr's approach actually
increases the splatter (any change you make in one function means having to
percolate that change up and down the chain of functions that it calls or that
call it) but also introduces greater safety and predictability.
 
-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, please try +44 (0)1273 64 2905.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100719/911f0b37/attachment.pgp>


More information about the darcs-users mailing list