Sorry! Must have hit "Reply" and not "Reply All". -KQ
On Wed, 4 Jul 2007 10:05:45 +0200, "Eric Y. Kow" <[EMAIL PROTECTED]> wrote: > Hi, > > Can I forward this to darcs-devel? > > On Tue, Jul 03, 2007 at 18:58:35 -0700, Kevin Quick wrote: > > On Tue, 3 Jul 2007 23:36:30 +0200, "Eric Y. Kow" <[EMAIL PROTECTED]> > > wrote: > > > > > > However, there are some cases where these links are not > > > > desireable. Examples include cases where the two repositories > > > > should have different ownership/file protections, etc. > > > > > > I think I've seen people bitten by this before, Bob and Alice on the > > > same file system, Bob does a darcs get of Alice's repository and is > > > stuck with files he cannot delete in his own directory, or something > > > like that. Problem is that I don't have a precise example in my head. > > > > The --nolinks isn't precisely intended to address the scenario you > > describe above. There's really two overlapping considerations here: > > correctness and policy management. Your scenario above is > > more of an issue of the first item (in the sense of setting > > fundamental file access privileges), and while --nolinks can partially > > help in this area, it's really more targeted to the policy > > consideration. > > > > A Unix-based example of your scenario above: > > > > Bob and Alice are both part of the "users" group, but Bob's umask is set > > such that any files he creates are readable only by him and not the > > group. Alice will be unable to work with patches created by Bob. > > > > However, this problem is only partially solved by the --nolinks > > argument. This could help Alice ensure that she's got her own > > copies of all of the patch files, but many patch of Bob's patches > > will simply be unreadable for a pull or get scenario. The better > > solution in this case is to ensure that umasks, privileges, and > > owner/group settings are set appropriately (as for any set of shared > > directories and files). > > > > There's no one right setting for this unfortunately, so it's hard to > > imagine darcs automatically apply or enforce correctness. Consider > > these scenarios: > > > > * Bob and Alice are part of the "projectx" group, and their > > repositories shouldn't be accessible to people not in that group. > > Their umasks should be set to provide group read (and write), but > > no world permissions. > > > > * A public repository, for which world read+write are needed. > > > > * A private repository for which only the owner should have read+write > > privileges. > > > > * A distribution repository for which the owner should have read+write > > privileges but group and/or world should have only read privileges. > > > > The --nolinks is most useful for policy management. As an example, > > consider a project with a number of contributors but which has a single > > release manager. This project might have two principle repositories: a > > "dev" repository and a "release" repository. > > > > The dev repository has read and write access for all members of the > > project group; any developer can push a patch into the dev repository. > > > > The release repository is readable by all members of the project group, > > but only writeable by the release manager. That individual only pushes > > vetted patches into the release repository. > > > > In this dev/release scenario, if the patches exist on the same > > machine/filesystem, a get/pull/push will usually result in hard-links > > to the same file. However, owner, group, and permissions for a > > hard-linked file are global to all links, so it's impossible to have > > different settings for patches shared by both repositories unless > > --nolinks is used to ensure that each repository has its own copy of > > the patch. > > > > > Kevin, do you think you could cook up a miminal example of a case where > > > it would be possible, but not desirable to make the hard link? > > > > Let me know if the above helps or if I've been a bit vague in spots and > > should clarify. I'd love to introduce a test into the darcs tests to > > demonstrate this, but that would require the use of multiple accounts > > with specific configurations, which doesn't lend itself to a > > self-contained automated testing environment (not to mention > > multi-platform). > > > > > > > > > This patch adds a --nolinks argument to get/push/pull that > > > > instructs darcs not to create links during these operations. > > > > > > Also, would it be possible for darcs simply to detect those cases, and > > > not create the links in those cases? > > > > Since these are policy issues, and for the reasons above, I don't think > > this is a tractable problem for auto-detection (unfortunately). > > > > Regards, > > -KQ > > > > -- > > -- > > Kevin Quick > > quick at org after sparq > > > > -- > Eric Kow http://www.loria.fr/~kow > PGP Key ID: 08AC04F9 Merci de corriger mon français. > -- -- Kevin Quick quick at org after sparq
pgpM4dhhs7Md1.pgp
Description: PGP signature
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
