| |||||||||||||
|
| |||||||||||||
Arch for CVS Users (Linux Journal)Arch for CVS Users (Linux Journal)Posted Jun 2, 2004 17:19 UTC (Wed) by iabervon (subscriber, #722)Parent article: Arch for CVS Users (Linux Journal) The thing that's difficult about arch is that it doesn't really support having multiple people working on the same archive. So if you have a CVS repository whose commit access is handled with g+ws and a group, you can't do the obvious switch. Instead what you're supposed to do is to have each developer have an archive, and they can pull chagesets from each other's archives; arch understands changesets so the constant branch merging shouldn't be too painful. I'm not sure how you're supposed to make the step of syncing with the rest of the group easy, though; as far as I can tell, you have to search all of the other members archives for changes that you might want to take, or have a single maintainer control the official version. It is possible to do the group access control, but you have to come up with some way of changing your umask when doing sftp and separately changing it (with a wrapper script) for local use.
(Log in to post comments)
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 17:41 UTC (Wed) by josh_stern (guest, #4868) [Link] The easiest setup if all developers are of equal priviledge isto make a new special user for each given project and have the special user own the repository. Every developer can then login as the special user, for instance via sftp. Deveoper identities are still preserved in the logs. But it would be nicer and more flexible if Arch eventually supported ACLs within its commit process.
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 18:36 UTC (Wed) by moffixx (guest, #22010) [Link] Arch's format is inherently log-structured. Changesets are just appended onto the archive. I'm not sure how fine grained you really want to get, but you can't forbid a checkin for one directory in an arch project while allowing all the others.You can, however, restrict access on a per-project basis. And if you really need stricter access control, then you probably want to do a more distributed method anyway. Have untrusted developers publish their own archives, and merge in from them what you feel is appropriate.
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 19:34 UTC (Wed) by josh_stern (guest, #4868) [Link] "you can't forbid a checkin for one directory in an arch project whileallowing all the others" Of course it could work that way. A detailed error would be reported, no checkin would occur, and the developer would find an alternative strategy - e.g. a) decide she didn't really need to modify that other directory, or b) get someone else with the necessary priviledge to do the checkin.
Arch for CVS Users (Linux Journal) Posted Jun 3, 2004 1:27 UTC (Thu) by mbp (guest, #2737) [Link] Oh, you're talking about allowing some users to commit to say ./doc/ but not anywhere else in the source tree?It's true that Arch can't directly support that, while Svn can. I would think that the way to do this under Arch would be to have a separate branch in which the documentation developers can work. A working directory can be assembled from several trees using Arch config specs, which are kind of like CVS modules. (In fact I suppose you could use CVS modules to allow per-directory commits, which I had not thought about before. Doesn't Mozilla do something like that?) In some ways this seems conceptually cleaner. It is somewhat more complex to set up, but that only has to be done once, then copied into the checkout instructions. On the other hand, I think it's a feature that Arch's version control is managed by OS permissions which are likely to be well-understood and stronger. You can also put the different branches on different machines, which might be a good idea if you really distrust those documentation guys. The idea of access control means something different in distributed systems. On Subversion, somebody not trusted to commit to a directory can really work on it. In distributed systems, people who are not trusted to commit at the moment can still do their own work and submit it for consideration.
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 18:32 UTC (Wed) by moffixx (guest, #22010) [Link] The article, in fact, describes precisely how multiple users may share an archive. I encourage you to read it!
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 21:30 UTC (Wed) by walters (subscriber, #7396) [Link] The thing that's difficult about arch is that it doesn't really support having multiple people working on the same archive. That's completely, totally false. See:
Arch for CVS Users (Linux Journal) Posted Jun 3, 2004 6:41 UTC (Thu) by mbp (guest, #2737) [Link] > So if you have a CVS repository whose commit access> is handled with g+ws and a group, you can't do the > obvious switch. Yes you can. It works fine. Why are jaberbon and piman repeatedly insisting on this page that it doesn't work when it plainly does? Did you even try it? OK, it's possible there's soemthing wierd on your machine, or you're hitting an arch bug, or Nick's instructions were less than perfectly clear. Leaving that aside, it works fine: if you have a shared writable directory, you can have a shared writable archive. Easy. In fact, even less is often needed than what Nick says. Many (most?) Linux machines have a umask of 002 by default and per-user groups. If you have this and you just chmod g+swx the directory, you're done. This is exactly the same issue that regularly fouls Subversion repos too.
Arch for CVS Users (Linux Journal) Posted Jun 3, 2004 6:47 UTC (Thu) by piman (subscriber, #8957) [Link] I never said that wasn't sufficient; I'm just trying to dispel dmarti's myth that Arch requires zero server-side setup. I consider creating a reasonable SSH policy server-side setup; in addition, see my last comment on what just plain doesn't work with SSH-only access (let alone zero-setup access).
Arch for CVS Users (Linux Journal) Posted Jun 5, 2004 4:26 UTC (Sat) by iabervon (subscriber, #722) [Link] I missed the part of the article which explained how to set up sftp tohave a non-default umask, but that's what I described in my third paragraph: some way to have sftp change the umask. Unlike CVS, arch doesn't handle g+s itself, but does something useless and mysterious in this case (you have a shared writing archive, but users steal the lock when they commit). The article also doesn't mention how you deal with local access to the repository or NFS access to the repository, the first of which I'm using, and the second of which (with CVS) I used at a previous company. I haven't tried Subversion to see what it does. The default umask on Debian (which is what we're using on the relevant systems) is 0022, so there are plenty of systems with this configuration.
Arch for CVS Users (Linux Journal) Posted Jun 3, 2004 11:14 UTC (Thu) by job (subscriber, #670) [Link] Linux has had ACLs for five years now, isn't it time to use them? It'seven all in the stable tree now. Works on ext2/3, xfs, jfs, reiser (a few still require a simple patch). There's no need to mess around with the group/owner-system in the few cases, like this one, where it is clear ACLs makes it easier for you. The right tools for the right job! (And tools taking advantage of this is tools done right.)
Arch for CVS Users (Linux Journal) Posted Jun 3, 2004 20:42 UTC (Thu) by josh_stern (guest, #4868) [Link] I'm also in favor of more future use of ACLs, but are you really sayingthat it is recommended to rely on ACLs for security with non ACL aware file modifying applications (including source control apps)? Why exactly do you expect that newly created and modified files will always get the intended attributes?
Arch for CVS Users (Linux Journal) Posted Jun 10, 2004 8:09 UTC (Thu) by job (subscriber, #670) [Link] For most repositorys my guess is that one inherited ACL should be enough.Arch is early in its development so perhaps it can be extended to handle the more complicated cases without too much work? I have no idea about this really so I should let someone else talk. I meant to illustrate the upside of leaving authentication to the operating system.
|
|
||||||||||||