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
pgpSlgERqnsl6.pgp
Description: PGP signature
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
