On Tue, Jan 27, 2009 at 12:41 PM, Dan <[email protected]> wrote: > suggest any concrete examples.. perhaps it would be easier to keep it all in > the > same repository, but force certain branches to require extra permissions??? so > public checkins could be kept in a '-public' branch, and only certain users > could merge them with the true 'truck' branch???? (i suspect managing the > permissions on such a repository and having to explain it to Joe Public could > get *really* difficult, so this may not be such a useful idea)
Maybe tag private branches with "developer:developerName" or "branch:private:developerName"? Perhaps that just opens up uncomfortable questions like "can other developers pull the private branch?" and "if not, why not?" Such questions suggest the need for a relatively flexible permissions system (which may or may not have other uses, like wiki entries only certain users can edit). i once implemented a document system for PHP which essentially modelled unix access rights for arbitrary DB objects. It was really useful, and i can imagine such an approach being useful here (where basically any artefact can be "permissioned"), but i think that such a system would add undue complexity and runtime overhead to fossil. sqlite authorizer functions might be a useful approach to retro-fit permissions without having to change existing fossil queries [too much]. > repository than the shared framework code, however to test them, i really need > them to be in the same root folder.. so the ability to check out multiple > repositories in to the same folder would be a HUGE bonus for my workflow.. To me it all seems like a big can of worms, but i've always avoided branches like the plague because they are, by nature, problematic in both implementation and proper usage. Cross-repo branches would, in my admittedly limited world view, be even more problematic. > I don't think this is particularly difficult to implement (in my VERY limited > understanding of how fossil works) since the files for each project are > essentially just "extra" files for the other project.. as long as I can > specify > which repository I mean when I am "adding" a file, then it all should just > work. The first problem i see there is the manifest file - it would need to be merged for each opened repo, each entry would have to be tagged as to which repo it belongs to, certain operations (e.g. commit) become more difficult because they have to loop over all affected repos. There are also potential problems with atomicity of a commit across multiple repos at once. As the number of repos goes up, the potential for an SHA1 collisions also theoretically goes up, but this is probably too small of a chance to be of concern. Another option, instead of merging the manifest file, is to rename it to "manifest.REPO_NAME", but that of course breaks down if a repo is renamed (in the same way that the home page of a repo gets "lost" when the repo is renamed), and still leaves the problem of the _FOSSIL_ file, which must have a static name because otherwise we wouldn't know how to find it (my assumption is that the proper manifest.REPO_NAME could be found once _FOSSIL_ has been opened and examined). > I would suggest that if multiple repositories are checked out in the same > folder > that any ADD, RM, UPDATE etc should be forced to specify the repository to use > as its source.. either provide an error or perhaps even a prompt in the CLI??? > ie "Multiple Repositories found, use [1,2,3]" etc.. Absolutely. > At the moment, I am manually copying ProjectA's files into each of the other > folders whenever I do an update, but that is starting to be very tedious.. That's the approach i'm taking as well, but i'll also stick to that approach because it's "tried and true" (though admittedly tedious, but not, IMO, as confusing as branches). The suggestion from Kees regarding using hard links may be an interesting way to help with this (at least for Unix users, which i assume most of us are). In summary: this is a can of worms just waiting to be opened. (That said, Richard has shown the world several times over that he can take on Raging Cans of Worms and win.) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
