Re: [fossil-users] Allow checkins on another repo

On May 12, 2015, at 11:45 PM, Steve Stefanovich wrote: > > What about nested checkouts? Which repo should it check to? I presume the > first _FOSSIL_ it finds. Yes. I can give you a real-world case where that happens, in fact. We have a repo that exists only to hold a set of files needed acro

Re: [fossil-users] Allow checkins on another repo

What about nested checkouts? Which repo should it check to? I presume the first _FOSSIL_ it finds. What if you make a typo that results in the path which is a valid changed file in unintended checkout? That would result in committing to wrong repo. ‎This could easily (certainly to me, at least)

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] Fossil error "fossil knows nothing about: C20131_IR_At7_OpSystem_ProjectFile.fossil"

On May 12, 2015, at 2:27 AM, Gary_Gabriel wrote: > > I get this error[1] with a commit: > fossil commit -m "12.05.2015. C20131_IR_At7_OpSystem_ProjectFile.tcl." --tag > "C20131_IR_At7_OpSystem_ProjectFile" --allow-empty > C20131_IR_At7_OpSystem_ProjectFile.fossil > error[1] fossil knows nothin

Re: [fossil-users] Automatic editor detection.

Thus said John Found on Tue, 12 May 2015 23:33:00 +0300: > BTW, I found shorter form, without defining variable: I usually just use: EDITOR=vi; export EDITOR :-) Andy -- TAI64 timestamp: 400055526e2a ___ fossil-users mailing list fossil-users@lis

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] Automatic editor detection.

On Tue, May 12, 2015 at 10:33 PM, John Found wrote: > On Tue, 12 May 2015 20:43:45 +0200 > Stephan Beal wrote: > > > editor=$(xdg-mime query default text/plain | sed 's/\..*//') $editor > > > > No, it does not works on the first use in the console. At the second time, > only $editor is enough. >

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] Automatic editor detection.

On Tue, 12 May 2015 20:43:45 +0200 Stephan Beal wrote: > editor=$(xdg-mime query default text/plain | sed 's/\..*//') $editor > No, it does not works on the first use in the console. At the second time, only $editor is enough. Some distributions have $editor environment variable predefined. I

Re: [fossil-users] Automatic editor detection.

On Tue, 12 May 2015 20:43:45 +0200 Stephan Beal wrote: > editor=$(xdg-mime query default text/plain | sed 's/\..*//') $editor > No, it does not works on the first use in the console. At the second time, only $editor is enough. Some distributions have $editor environment variable predefined. I

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

[fossil-users] Allow checkins on another repo

“fossil ci” currently allows you to specify file or directory names, which causes it to restrict the checkin to the named entities. This is very useful within a single repository, but it breaks down when you try to use it with multiple repo checkouts. Fossil doesn’t take those names into accou

Re: [fossil-users] Automatic editor detection.

On Tue, May 12, 2015 at 8:35 PM, John Found wrote: > Maybe this trick will be useful for someone. > > Using the same repository from several Linux distributions, I set the > editor following way: > > editor=$(xdg-mime query default text/plain | sed 's/\..*//') && $editor > fyi: the && is ext

[fossil-users] Automatic editor detection.

Maybe this trick will be useful for someone. Using the same repository from several Linux distributions, I set the editor following way: editor=$(xdg-mime query default text/plain | sed 's/\..*//') && $editor This way, on every distro, the default editor is detected and used. For me it wor

[fossil-users] fossil bundle technote

Hello, How can I include a technote in a bundle? ​RR​ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[fossil-users] Fossil error "fossil knows nothing about: C20131_IR_At7_OpSystem_ProjectFile.fossil"

Hi List, Can someone help me debug this fossil problem. Background. This repo was moved to a new PC. I get this error[1] with a commit: fossil commit -m "12.05.2015. C20131_IR_At7_OpSystem_ProjectFile.tcl." --tag "C20131_IR_At7_OpSystem_ProjectFile" --allow-empty C20131_IR_At7_OpSystem_Proje