Re: [fossil-users] Feature idea: Protected branches

On Thu, May 14, 2015 at 4:37 PM, paul wrote: > > But a developer could just disable the hook code in the local repository? > There wouldn't be anything to stop that. Or am I misunderstanding something? > If a dev wants to do that, he could. But a dev who is merely distracted, is unlikely to do th

Re: [fossil-users] Feature idea: Protected branches

On 14/05/15 20:04, Ron W wrote: I don't think it's likely a distracted dev will override or subvert the rules imposed by the hook mechanism. A dev determined to get around the rules is a completely different issue. But a developer could just disable the hook code in the local repository? Th

Re: [fossil-users] Feature idea: Protected branches

On Thu, May 14, 2015 at 1:51 PM, paul wrote: > It wouldn't offer much control over a distracted programmer, because > your local repo is always going to be under the full control of the user on > the local machine - no hacking required. > As I previously pointed out, with any DVCS - not just Fo

Re: [fossil-users] Feature idea: Protected branches

On 13/05/15 16:45, Ramon Ribó wrote: Hello, A reasonable solution could be a pre-commit hook, where the script in TH1 or TCL had access to the branch name of the commit and other details. As a result, the hook could accept the commit, raise a warning, ask for confirmation or deny the commit.

Re: [fossil-users] Feature idea: Protected branches

On Wed, May 13, 2015 at 11:45 AM, Ramon Ribó wrote: > A reasonable solution could be a pre-commit hook, where the script in TH1 > or TCL had access to the branch name of the commit and other details. As a > result, the hook could accept the commit, raise a warning, ask for > confirmation or deny

Re: [fossil-users] Feature idea: Protected branches

Hello, A reasonable solution could be a pre-commit hook, where the script in TH1 or TCL had access to the branch name of the commit and other details. As a result, the hook could accept the commit, raise a warning, ask for confirmation or deny the commit. This hook would not stop a determined hac

Re: [fossil-users] Feature idea: Protected branches

On Tue, May 12, 2015 at 1:51 PM, Warren Young wrote: > On May 12, 2015, at 2:31 PM, Matt Welland wrote: > > > > Does your team use Unix file permissions to prevent people from viewing > files they have no right to be looking at? > > Are you suggesting that Fossil needs to implement a per-artifac

Re: [fossil-users] Feature idea: Protected branches

On 5/12/2015 9:23 PM, Richard Hipp wrote: > On 5/12/15, Ron W wrote: >> On the other hand, if [you] require such strict controls, >> a DVCS, whether Fossil, Git or other, is likely not the tool you need. > > So the only way for the central repo to enforce strict controls is to > carefully analyze

Re: [fossil-users] Feature idea: Protected branches

On Tue, May 12, 2015 at 9:27 PM, Warren Young wrote: > On May 12, 2015, at 5:51 PM, Scott Robison > wrote: > > > > the difficult part comes in the sync, since they only deal with > artifacts. Once someone clones the repo, they have full access to that copy > to do with as they please. > > I’m no

Re: [fossil-users] Feature idea: Protected branches

On May 12, 2015, at 5:51 PM, Scott Robison wrote: > > the difficult part comes in the sync, since they only deal with artifacts. > Once someone clones the repo, they have full access to that copy to do with > as they please. I’m not so sure about that. I think all that is required is for the

Re: [fossil-users] Feature idea: Protected branches

On 5/12/15, Ron W wrote: > On the other hand, if [you] require such strict controls, > a DVCS, whether Fossil, Git or other, is likely not the tool you need. Thanks, Ron. I was going to make this point earlier myself... In distributed VCS like Fossil or Git or Hg, the developer has direct acces

Re: [fossil-users] Feature idea: Protected branches

On Tue, May 12, 2015 at 7:51 PM, Scott Robison wrote: > > None of these are impossible obstacles to overcome, but taken together as > a whole they do mean there is a significant amount of work to be done to > ensure policies are enforced, because the first time a policy is not > enforced for any r

Re: [fossil-users] Feature idea: Protected branches

On Tue, May 12, 2015 at 5:05 PM, Andy Goth wrote: > On 5/12/2015 3:38 PM, Warren Young wrote: > > The OP said that each of his clients has artifacts in the repository > > that can’t be shared with other sub-sections of the repository, for > > unspecified reasons. He also talked about a shared co

Re: [fossil-users] Feature idea: Protected branches

On 5/12/2015 3:38 PM, Warren Young wrote: > The OP said that each of his clients has artifacts in the repository > that can’t be shared with other sub-sections of the repository, for > unspecified reasons. He also talked about a shared code base. That’s > an N+1 situation. Let me make a correcti

Re: [fossil-users] Feature idea: Protected branches

On May 12, 2015, at 2:31 PM, Matt Welland wrote: > > Does your team use Unix file permissions to prevent people from viewing files > they have no right to be looking at? Are you suggesting that Fossil needs to implement a per-artifact ACL system? Yes, I realize this is a slippery-slope argumen

Re: [fossil-users] Feature idea: Protected branches

On 12/05/15 21:31, Matt Welland wrote: On Mon, May 11, 2015 at 2:17 PM, Warren Young > wrote: On May 11, 2015, at 10:48 AM, Andy Goth mailto:andrew.m.g...@gmail.com>> wrote: > > X group manages Y branch. Didn’t we all learn how to share in kindergarte

Re: [fossil-users] Feature idea: Protected branches

On May 12, 2015, at 6:23 AM, Abilio Marques wrote: > > If I go to any of my repositories in fossil, open Admin > Users, and I see a > list of permissions. There is one for deleting wiki and tickets, one for > append to tickets, one for check out versions, and so on. All of the permissions you’

Re: [fossil-users] Feature idea: Protected branches

On Mon, May 11, 2015 at 2:17 PM, Warren Young wrote: > On May 11, 2015, at 10:48 AM, Andy Goth wrote: > > > > X group manages Y branch. > > Didn’t we all learn how to share in kindergarten? > > If it makes sense for multiple groups with disparate interests to all be > working on a single common

Re: [fossil-users] Feature idea: Protected branches

On Mon, May 11, 2015 at 11:52 PM, Andy Goth wrote: > On 5/11/2015 3:08 PM, Ron W wrote: > > Another possible work-around (besides what Andy and I suggested) would > > be for contributing devs to mark their trunks (and other designated > > "protected" branches) as private. > > I've considered this

Re: [fossil-users] Feature idea: Protected branches

I kept my mind going around the initial response of Mr. Hipp, plus I kept reading the emails. And I don't want to continue a fight over this. But I must say some things, specially to get my mind clear on the idea of policy vs. mechanism. If I go to any of my repositories in fossil, open Admin > U

Re: [fossil-users] Feature idea: Protected branches

On May 11, 2015 8:40 AM, "Andy Goth" wrote: > > On 5/11/2015 9:10 AM, Richard Hipp wrote: > > On 5/11/15, Abilio Marques wrote: > >> I recall seeing no way of detecting a "push" to a specific > >> branch. All I saw were deltas and stuff like that. > > > > To change Fossil to have the ability to p

Re: [fossil-users] Feature idea: Protected branches

On May 11, 2015, at 9:46 PM, Andy Goth wrote: > > We have many customers with different requirements and firm restrictions > on what can be shared between them, though we share as much as we can so > that we're not duplicating effort. In that case, I’d split your current repo into N+1 Fossil rep

Re: [fossil-users] Feature idea: Protected branches

On 5/11/2015 3:08 PM, Ron W wrote: > Another possible work-around (besides what Andy and I suggested) would > be for contributing devs to mark their trunks (and other designated > "protected" branches) as private. > > Then, when working on a feature/fix branch, "fossil publish branchname" > to mak

Re: [fossil-users] Feature idea: Protected branches

On 5/11/2015 4:17 PM, Warren Young wrote: > On May 11, 2015, at 10:48 AM, Andy Goth wrote: >> >> X group manages Y branch. > > Didn’t we all learn how to share in kindergarten? > > If it makes sense for multiple groups with disparate interests to all > be working on a single common code base, wi

Re: [fossil-users] Feature idea: Protected branches

On May 11, 2015, at 10:48 AM, Andy Goth wrote: > > X group manages Y branch. Didn’t we all learn how to share in kindergarten? If it makes sense for multiple groups with disparate interests to all be working on a single common code base, with each group on a different branch, you can treat in

Re: [fossil-users] Feature idea: Protected branches

On Mon, May 11, 2015 at 10:51 AM, Abilio Marques wrote: > > Note also that this goes against one of the founding principles of >> Fossil: that the VCS should implement mechanism not policy. That is >> to say, details of who should be able to check-in to which branches >> and whatnot should not b

Re: [fossil-users] Feature idea: Protected branches

Thus said Abilio Marques on Mon, 11 May 2015 09:27:53 -0430: > I wondered back then, what would it take to implement this for fossil. > The first thing that popped to my head was the protocol. I gave a > quick glance back then, and I recall seeing no way of detecting a > "push" to a spe

Re: [fossil-users] Feature idea: Protected branches

On 5/11/2015 11:57 AM, Richard Hipp wrote: > On 5/11/15, Andy Goth wrote: >> My wishlist derives from my organization's needs which are currently >> being met by ClearCase ... > > My "mechanism not policy" rule derives from some very bad experiences > with ClearCase... I understand completely, a

Re: [fossil-users] Feature idea: Protected branches

On Mon, May 11, 2015 at 12:48 PM, Andy Goth wrote: > > Of course this is far too much to ask to directly build into Fossil, but > that doesn't mean Fossil's scripting mechanism can't be extended to the > point where it can enforce this policy. > I have yet to even experiment with Fossil's recentl

Re: [fossil-users] Feature idea: Protected branches

On 5/11/15, Andy Goth wrote: > My wishlist derives from > my organization's needs which are currently being met by ClearCase ... My "mechanism not policy" rule derives from some very bad experiences with ClearCase... -- D. Richard Hipp d...@sqlite.org _

Re: [fossil-users] Feature idea: Protected branches

On 5/11/2015 11:39 AM, Andy Goth wrote: > On 5/11/2015 11:29 AM, Ron W wrote: >> If the project is too big for re-cloning every time there is an >> accidental commit to trunk, then you could require the contributing devs >> to send "bundles" to the integrator. On import, commits from a bundle >> ha

Re: [fossil-users] Feature idea: Protected branches

On 5/11/2015 11:29 AM, Ron W wrote: > If the project is too big for re-cloning every time there is an > accidental commit to trunk, then you could require the contributing devs > to send "bundles" to the integrator. On import, commits from a bundle > have a special status that allows them to be un-

Re: [fossil-users] Feature idea: Protected branches

On Mon, May 11, 2015 at 10:51 AM, Abilio Marques wrote: > > Note also that this goes against one of the founding principles of >> Fossil: that the VCS should implement mechanism not policy. That is >> to say, details of who should be able to check-in to which branches >> and whatnot should not b

Re: [fossil-users] Feature idea: Protected branches

On 5/11/2015 9:10 AM, Richard Hipp wrote: > On 5/11/15, Abilio Marques wrote: >> I recall seeing no way of detecting a "push" to a specific >> branch. All I saw were deltas and stuff like that. > > To change Fossil to have the ability to prevent pushes to certain > branches, we would have to add k

Re: [fossil-users] Feature idea: Protected branches

> Note also that this goes against one of the founding principles of > Fossil: that the VCS should implement mechanism not policy. That is > to say, details of who should be able to check-in to which branches > and whatnot should not be enforced by the VCS. Project policies need > to be enforced

Re: [fossil-users] Feature idea: Protected branches

On 5/11/15, Abilio Marques wrote: > I recall seeing no way of detecting a "push" to a specific > branch. All I saw were deltas and stuff like that. > > Am I wrong? or is there a way the server could forbid an user to push to > some branches and give an error? You are correct. The push/pull logic

[fossil-users] Feature idea: Protected branches

After using git for a while with a group of other 5 people who sometimes forgot our policy that only one of us had the authority (actually the responsibility) to work with the "master" branch, having to clean each "mistake" later, we discovered the platform we had been using actually offered a feat