Re: [fossil-users] pushing only specific branches to specific servers?

[Gour]

On Tue, 11 Dec 2012 18:59:59 -0600
"C. Thomas Stover"  wrote:

> Is there some way to push just a specific branch to a server other
> than the private branch feature? 

No, but it was discussed in the past...btw, I'd also like to have
selective push/pull feature.


Sincerely,
Gour

-- 
He who is regulated in his habits of eating, sleeping, recreation 
and work can mitigate all material pains by practicing the yoga system.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] pushing only specific branches to specific servers?

[C. Thomas Stover]

Is there some way to push just a specific branch to a server other than
the private branch feature? For example branch A and B are both stored
locally, and are both pushed to server 1, yet only branch B is pushed
to server 2.

___
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] why does `fossil rm' not do the "real" thing?

[Jan Danielsson]

On 12/11/12 23:08, K wrote:
> I agree with Themba. I like that Fossil is a separate repo 'world' from my 
> files. If this boundary is to be pierced, I think it should require passing 
> in some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in 
> this example representing "sync".
> 
> I would like some friendly tip text after rm/et al are ran, such as:
> 
> "You have removed file1.h, file1.c from repo foo, you may want to remove them 
> from your working copy."

> Seems like a great way to remind, teach, and help all in-context and with 
> minimal overhead.

   Say during your lifetime you'll (re)move 1000 files in fossil
repositories. That means you'll in practice perform 2000 (re)move
operations (once in metadata, and once in the filesystem). At what point
would one expect to have been sufficiently reminded and taught how to
(re)move files?

   Personally, I have never learned anything of value from having to
(re)move files twice.

   And I don't really buy the "It's safer" argument either. I have
several times become confused over what operations I have actually
performed because the file-system isn't in sync with the operations I
have performed; and becoming confused over what operations one has
performed because the filesystem doesn't reflect it is not "safe".

   I'm willing to bet that the number of times people will type "fossil
mv/rm X Y" and not actually want to mv/rm X to Y just afterwards is
vanishingly small. More to the point; let's reverse your "-s"-flag; I.e.:

   $ fossil mv X Y

   ... renames X to Y (metadata and filesystem).

   $ fossil -d mv X Y

   ... as in "Don't actually move" will only change the metadata, and
the user can then use the mv command afterwards to manually rename/move
the file in the filesystem.

   The last option doesn't make any sense at all. Which is sort of my
point.. I think such an option would be used roughly zero times; but
your proposed "-s" would be used almost 100% of the time (when people
learn about it). And this goes back to that "ten things I hate about
git"-list; when commands counter-intuitively require extra flags to get
the canonical behavior.

   (I did some serious refactoring recently which involved lots of mv
and a few rm, and it really annoyed me that my computer, which is
supposedly a machine for automating tasks, required me to perform an
extra manual step for each mv and rm). (Yes, I ended up scripting it in
the end .. but that just further annoyed me; why do I need to script
operations in fossil to get the canonical behavior?).

   I too am a little skeptical about adding too many settings to fossil,
but this is definitely one that I would think merits a setting if the
current (default) behavior is kept in 2.0.

   Sorry if this came out as a rant; it's not directed at anyone
personally, but like I said, I battled fossil rm/mv recently and I'm
still not completely over it. No flame-bait intended.

-- 
Kind regards,
Jan Danielsson

___
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] why does `fossil rm' not do the "real" thing?

[j. v. d. hoff]

On Tue, 11 Dec 2012 22:50:06 +0100, Themba Fletcher  
 wrote:



Sorry to drag up an old thread, but I'm just checking back in after a
lengthy absence.

On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek   
wrote:

Weighing in on this, finally:

It's interesting to me that everyone speculates that this *might* break
things for some hypothetical person, and *might* bite someone, but has
anyone here ever been bitten by it?


It's the "what if" that bothers me. I use fossil as a safety net to
manage an ungodly number of small maintenance projects, so I'm often
not the original author of the project, and am almost never really
comfortable with the code base I'm modifying.

When I sync a code base to my machine and "fossil add . --dotfiles" I
really appreciate the fact that I can trust fossil not to touch the
disk if I accidentally add something that I don't want in there and
have to remove it.

In the presence of shabby and poorly maintained deploy/sync scripts,
solo use of fossil, unknown modifications to the master since the last
checkin, etc., the consequences of removing something from my local
copy could be pretty embarrassing -- ie I could potentially blow away
the only working copy of a new cusomer's web app. Not to say that I
couldn't adjust to a new set of danger points, but that I do really
appreciate fossil's current behavior.




And is it not something that "fossil revert" could undo?



Is it? What about:

fossil add .
(whoops) -> fossil rm something
fossil commit
(take a phone call and forget it's fossil 2.0)
sync up

Now the files are gone locally, they're gone on the remote site, and
fossil revert isn't going to help. This is obviously a workflow /
deploy problem at its root, but it's a bit of sloppiness that fossil's
current behavior forgives and the proposed behavior would not.



I don't mind avoiding the change until a 2.0 release, but I worry about
making it a setting, because I prescribe to the idea that settings add
complexity both for users and developers.



I agree about minimizing the extra overhead of a setting, but I come
down personally on the side of "it's working fine, so please don't
touch it." Maybe my use case varies from the norm, but I don't do
fossil rm all that often and, when I do, the extra overhead of having
to do "Up arrow, Ctrl-A, Alt-D, Return" afterwards doesn't bother me
at all. I like explicitly taking care of this as a second deliberate
step.

My $0.10 adjusted for inflation: keep the existing behavior until 2.0,  
then

just change it. There are plenty of settings already, please don't add
another, especially for something that we're all speculating might  
affect

someone who can't just revert for whatever reason.


So, respectfully disagree. For me it's about not having to learn new
rules about when fossil will touch my files and when it will not.


for me it's about what is the most sane (or probably expected) default  
behavior for the majority of users.
this question has been answered several times by the developers/users of  
other SCMs (hg, svn, ...) to the
extent that `rm' and 'mv' should act on the files in the checkout as well.  
for me, they were right: when
executing commands via  the SCM (fossil in the present context) one can  
_expect_ that something will happen
to the checkout and that fossil's opinion of what the state of the project  
is should be in sync with the
checkout as far as possible. _usually_ `fossil mv' and `fossil rm' should  
imply that the action is applied
to the checkout as well (do the rename or deletion of the file). more  
often than not (I'd say) that's what
the user will want to happen. and that's what the default behavior should  
cover.


of course I understand that this might exactly be _not_ your use case. but  
we are talking about _default_ behavior (and possibly delegating diverging  
behavior to options). in my use case I _always_ have to mv/rm (mv is  
especially bad, if forgotten) the checkout files manually and my suspicion  
is that's exactly what the majority of users will do currently. which  
would indicate that the current behavior is  suboptimal.


best regards,
joerg




Best Regards,

Themba
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] why does `fossil rm' not do the "real" thing?

[Matt Welland]

On Tue, Dec 11, 2012 at 3:08 PM, K  wrote:

> I agree with Themba. I like that Fossil is a separate repo 'world' from my
> files. If this boundary is to be pierced, I think it should require passing
> in some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in
> this example representing "sync".
>
> I would like some friendly tip text after rm/et al are ran, such as:
>
> "You have removed file1.h, file1.c from repo foo, you may want to remove
> them from your working copy."
>
> Seems like a great way to remind, teach, and help all in-context and with
> minimal overhead.
>


I thought that there was some degree of agreement that the destructive
commands such as rm and mv would *require* -f (or some other switch) to do
the same action on disk.

If that is not the case then I share Themba's concern. This *will* cause
grief. There is no need to make this configurable.

My preference is to mirror the behavior of mecurial or git. Git's approach
of checking that the file is unchanged from the head before doing the rm is
safe and convenient.





>
> ^K
>
>
> on Dec 11, 2012, Themba Fletcher  wrote:
> >
> >Sorry to drag up an old thread, but I'm just checking back in after a
> >lengthy absence.
> >
> >On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek 
> wrote:
> >> Weighing in on this, finally:
> >>
> >> It's interesting to me that everyone speculates that this *might* break
> >> things for some hypothetical person, and *might* bite someone, but has
> >> anyone here ever been bitten by it?
> >
> >It's the "what if" that bothers me. I use fossil as a safety net to
> >manage an ungodly number of small maintenance projects, so I'm often
> >not the original author of the project, and am almost never really
> >comfortable with the code base I'm modifying.
> >
> >When I sync a code base to my machine and "fossil add . --dotfiles" I
> >really appreciate the fact that I can trust fossil not to touch the
> >disk if I accidentally add something that I don't want in there and
> >have to remove it.
> >
> >In the presence of shabby and poorly maintained deploy/sync scripts,
> >solo use of fossil, unknown modifications to the master since the last
> >checkin, etc., the consequences of removing something from my local
> >copy could be pretty embarrassing -- ie I could potentially blow away
> >the only working copy of a new cusomer's web app. Not to say that I
> >couldn't adjust to a new set of danger points, but that I do really
> >appreciate fossil's current behavior.
> >
> >
> >>
> >> And is it not something that "fossil revert" could undo?
> >>
> >
> >Is it? What about:
> >
> >fossil add .
> >(whoops) -> fossil rm something
> >fossil commit
> >(take a phone call and forget it's fossil 2.0)
> >sync up
> >
> >Now the files are gone locally, they're gone on the remote site, and
> >fossil revert isn't going to help. This is obviously a workflow /
> >deploy problem at its root, but it's a bit of sloppiness that fossil's
> >current behavior forgives and the proposed behavior would not.
> >
> >
> >> I don't mind avoiding the change until a 2.0 release, but I worry about
> >> making it a setting, because I prescribe to the idea that settings add
> >> complexity both for users and developers.
> >>
> >
> >I agree about minimizing the extra overhead of a setting, but I come
> >down personally on the side of "it's working fine, so please don't
> >touch it." Maybe my use case varies from the norm, but I don't do
> >fossil rm all that often and, when I do, the extra overhead of having
> >to do "Up arrow, Ctrl-A, Alt-D, Return" afterwards doesn't bother me
> >at all. I like explicitly taking care of this as a second deliberate
> >step.
> >
> >> My $0.10 adjusted for inflation: keep the existing behavior until 2.0,
> then
> >> just change it. There are plenty of settings already, please don't add
> >> another, especially for something that we're all speculating might
> affect
> >> someone who can't just revert for whatever reason.
> >
> >So, respectfully disagree. For me it's about not having to learn new
> >rules about when fossil will touch my files and when it will not.
> >
> >Best Regards,
> >
> >Themba
> >___
> >fossil-users mailing list
> >fossil-users@lists.fossil-scm.org
> >http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> >
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
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] why does `fossil rm' not do the "real" thing?

[K]

I agree with Themba. I like that Fossil is a separate repo 'world' from my 
files. If this boundary is to be pierced, I think it should require passing in 
some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in this 
example representing "sync".

I would like some friendly tip text after rm/et al are ran, such as:

"You have removed file1.h, file1.c from repo foo, you may want to remove them 
from your working copy."

Seems like a great way to remind, teach, and help all in-context and with 
minimal overhead.

^K


on Dec 11, 2012, Themba Fletcher  wrote:
>
>Sorry to drag up an old thread, but I'm just checking back in after a
>lengthy absence.
>
>On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek  wrote:
>> Weighing in on this, finally:
>>
>> It's interesting to me that everyone speculates that this *might* break
>> things for some hypothetical person, and *might* bite someone, but has
>> anyone here ever been bitten by it?
>
>It's the "what if" that bothers me. I use fossil as a safety net to
>manage an ungodly number of small maintenance projects, so I'm often
>not the original author of the project, and am almost never really
>comfortable with the code base I'm modifying.
>
>When I sync a code base to my machine and "fossil add . --dotfiles" I
>really appreciate the fact that I can trust fossil not to touch the
>disk if I accidentally add something that I don't want in there and
>have to remove it.
>
>In the presence of shabby and poorly maintained deploy/sync scripts,
>solo use of fossil, unknown modifications to the master since the last
>checkin, etc., the consequences of removing something from my local
>copy could be pretty embarrassing -- ie I could potentially blow away
>the only working copy of a new cusomer's web app. Not to say that I
>couldn't adjust to a new set of danger points, but that I do really
>appreciate fossil's current behavior.
>
>
>>
>> And is it not something that "fossil revert" could undo?
>>
>
>Is it? What about:
>
>fossil add .
>(whoops) -> fossil rm something
>fossil commit
>(take a phone call and forget it's fossil 2.0)
>sync up
>
>Now the files are gone locally, they're gone on the remote site, and
>fossil revert isn't going to help. This is obviously a workflow /
>deploy problem at its root, but it's a bit of sloppiness that fossil's
>current behavior forgives and the proposed behavior would not.
>
>
>> I don't mind avoiding the change until a 2.0 release, but I worry about
>> making it a setting, because I prescribe to the idea that settings add
>> complexity both for users and developers.
>>
>
>I agree about minimizing the extra overhead of a setting, but I come
>down personally on the side of "it's working fine, so please don't
>touch it." Maybe my use case varies from the norm, but I don't do
>fossil rm all that often and, when I do, the extra overhead of having
>to do "Up arrow, Ctrl-A, Alt-D, Return" afterwards doesn't bother me
>at all. I like explicitly taking care of this as a second deliberate
>step.
>
>> My $0.10 adjusted for inflation: keep the existing behavior until 2.0, then
>> just change it. There are plenty of settings already, please don't add
>> another, especially for something that we're all speculating might affect
>> someone who can't just revert for whatever reason.
>
>So, respectfully disagree. For me it's about not having to learn new
>rules about when fossil will touch my files and when it will not.
>
>Best Regards,
>
>Themba
>___
>fossil-users mailing list
>fossil-users@lists.fossil-scm.org
>http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
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] why does `fossil rm' not do the "real" thing?

[Themba Fletcher]

Sorry to drag up an old thread, but I'm just checking back in after a
lengthy absence.

On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek  wrote:
> Weighing in on this, finally:
>
> It's interesting to me that everyone speculates that this *might* break
> things for some hypothetical person, and *might* bite someone, but has
> anyone here ever been bitten by it?

It's the "what if" that bothers me. I use fossil as a safety net to
manage an ungodly number of small maintenance projects, so I'm often
not the original author of the project, and am almost never really
comfortable with the code base I'm modifying.

When I sync a code base to my machine and "fossil add . --dotfiles" I
really appreciate the fact that I can trust fossil not to touch the
disk if I accidentally add something that I don't want in there and
have to remove it.

In the presence of shabby and poorly maintained deploy/sync scripts,
solo use of fossil, unknown modifications to the master since the last
checkin, etc., the consequences of removing something from my local
copy could be pretty embarrassing -- ie I could potentially blow away
the only working copy of a new cusomer's web app. Not to say that I
couldn't adjust to a new set of danger points, but that I do really
appreciate fossil's current behavior.


>
> And is it not something that "fossil revert" could undo?
>

Is it? What about:

fossil add .
(whoops) -> fossil rm something
fossil commit
(take a phone call and forget it's fossil 2.0)
sync up

Now the files are gone locally, they're gone on the remote site, and
fossil revert isn't going to help. This is obviously a workflow /
deploy problem at its root, but it's a bit of sloppiness that fossil's
current behavior forgives and the proposed behavior would not.


> I don't mind avoiding the change until a 2.0 release, but I worry about
> making it a setting, because I prescribe to the idea that settings add
> complexity both for users and developers.
>

I agree about minimizing the extra overhead of a setting, but I come
down personally on the side of "it's working fine, so please don't
touch it." Maybe my use case varies from the norm, but I don't do
fossil rm all that often and, when I do, the extra overhead of having
to do "Up arrow, Ctrl-A, Alt-D, Return" afterwards doesn't bother me
at all. I like explicitly taking care of this as a second deliberate
step.

> My $0.10 adjusted for inflation: keep the existing behavior until 2.0, then
> just change it. There are plenty of settings already, please don't add
> another, especially for something that we're all speculating might affect
> someone who can't just revert for whatever reason.

So, respectfully disagree. For me it's about not having to learn new
rules about when fossil will touch my files and when it will not.

Best Regards,

Themba
___
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] (Another?) fossil wrapper script

[j. v. d. hoff]

On Tue, 11 Dec 2012 13:58:41 +0100, Marc Simpson  wrote:


Thanks Joerg,

I've just pushed a fix -- can you try it out and let me know whether it
resolves the issue



yes it does. thanks.

j.





Best,
Marc

On Tue, Dec 11, 2012 at 5:51 PM, j. v. d. hoff  
wrote:



thanks for this script which looks promising.
first bug report: I see interference with the `nano' editor (which is  
set
as my 'checkin editor' due to its low latency): `nano' is keyboard  
driven

and uses the command `^X' (CNTRL-X) for "save and exit". when using `fsl
ci' the editor opens all right and I can enter the commit message.  
CNTRL-X

however is not recognized as a command any more but rather is taken as
verbatim input: no way to leave the editor except killing the window.  
this

does happen only when issuing `fsl ci'
`fossil ci' behaves as expected.

regards,
joerg



On Tue, 11 Dec 2012 11:46:37 +0100, Marc Simpson   
wrote:


 Hi all,


I've recently written a simple wrapper for Fossil with the goal of
providing an improved CLI experience and thought others might find it
useful.

The script is written in Tcl/Expect and provides the following  
features:


   * Command aliasing
   * Output filtering
   * A number of preconfigured aliases, filters for colouring output

Though still inchoate, you should be able to use it as you would
`fossil' on the command line.

If you're interested, feel free to clone from
http://fossil.0branch.com/fsl/**home  
or download `fsl' directly:

http://fossil.0branch.com/fsl/**artifact/**f57c7ecf8c4db2a9990b40ee21e763
**7a1374f45e
.
The code is ISC licensed (likely overkill for such a simple script).

# Details

Out of the box, a number of filters and aliases are defined in
~/.fslrc (created on first run):

   * Aliases ('->' indicates the expansion)
  * '.' -> 'changes'
  * 'd' -> 'diff'
  * ',' -> 'ui'
  * 'log'   -> 'timeline'
  * 'heads' -> 'leaves'

   * Filters (all of which colour output)
  * 'diff'
 * 'fsl d'
  * 'log_entry'
 * 'fsl leaves', 'fsl timeline'
  * 'status'
 * 'fsl changes', 'fsl status', 'fsl timeline', 'fsl add',
   'fsl rm', 'fsl addremove'

You can see a summary of these definitions using the `fsl wrapper'
pseudo-command:

  $ fsl wrapper
  Aliases: . d , log heads
  Filters: changes status timeline add rm addremove leaves d

The configuration file is a Tcl script: you can define `proc's (for
helper functions) and employ them in your filters. Definitions will
end up in the `config::fslrc' namespace so you needn't worry about
clobbering predefined functions. Since the script makes heavy use of
dictionaries, it requires Tcl >= 8.5.

Alias declarations are trivial; their second argument can be a
bareword or quoted string, thereby allowing expansions to provide
switches if required, e.g.

  alias log  timeline
  alias history {timeline -n 100}

Filters are named, allowing them to be referenced elsewhere in your
configuration script. Their structure is:

  filter   

If you filter on a fossil command like `diff', aliases of this command
(by default, `d') will also be filtered. Conversely, filtering on an
alias (`d'), leaves its expansion (`diff') untouched. Also note that
more than one filter may apply to a given command: under the default
configuration, the timeline will be filtered by both `status' and
`log_entry'.

A filter body can reference the current output line via the implicitly
defined $line variable. By way of example, here's the `log_entry'
filter:

  filter log_entry {leaves timeline} {
  if {[regexp "^=== .* ===" $line]} {
  coloured blue $line
  } else {
  regsub -all {\[[A-Fa-f0-9]+\]} $line [coloured yellow &]
  }
  }

Useful functions defined by the script are:

   * `coloured' (for colouring output)
   * `alias?'
   * `filter?'
   * `empty?' and `prefix?' (simple utility functions)

Patches, criticisms, suggestions etc. are welcome.

Best,
Marc




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
__**_
fossil-users mailing list
fossil-users@lists.fossil-scm.**org 
http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] (Another?) fossil wrapper script

[Marc Simpson]

Thanks Joerg,

I've just pushed a fix -- can you try it out and let me know whether it
resolves the issue?

Best,
Marc

On Tue, Dec 11, 2012 at 5:51 PM, j. v. d. hoff wrote:

> thanks for this script which looks promising.
> first bug report: I see interference with the `nano' editor (which is set
> as my 'checkin editor' due to its low latency): `nano' is keyboard driven
> and uses the command `^X' (CNTRL-X) for "save and exit". when using `fsl
> ci' the editor opens all right and I can enter the commit message. CNTRL-X
> however is not recognized as a command any more but rather is taken as
> verbatim input: no way to leave the editor except killing the window. this
> does happen only when issuing `fsl ci'
> `fossil ci' behaves as expected.
>
> regards,
> joerg
>
>
>
> On Tue, 11 Dec 2012 11:46:37 +0100, Marc Simpson  wrote:
>
>  Hi all,
>>
>> I've recently written a simple wrapper for Fossil with the goal of
>> providing an improved CLI experience and thought others might find it
>> useful.
>>
>> The script is written in Tcl/Expect and provides the following features:
>>
>>* Command aliasing
>>* Output filtering
>>* A number of preconfigured aliases, filters for colouring output
>>
>> Though still inchoate, you should be able to use it as you would
>> `fossil' on the command line.
>>
>> If you're interested, feel free to clone from
>> http://fossil.0branch.com/fsl/**home or 
>> download `fsl' directly:
>> http://fossil.0branch.com/fsl/**artifact/**f57c7ecf8c4db2a9990b40ee21e763
>> **7a1374f45e
>> .
>> The code is ISC licensed (likely overkill for such a simple script).
>>
>> # Details
>>
>> Out of the box, a number of filters and aliases are defined in
>> ~/.fslrc (created on first run):
>>
>>* Aliases ('->' indicates the expansion)
>>   * '.' -> 'changes'
>>   * 'd' -> 'diff'
>>   * ',' -> 'ui'
>>   * 'log'   -> 'timeline'
>>   * 'heads' -> 'leaves'
>>
>>* Filters (all of which colour output)
>>   * 'diff'
>>  * 'fsl d'
>>   * 'log_entry'
>>  * 'fsl leaves', 'fsl timeline'
>>   * 'status'
>>  * 'fsl changes', 'fsl status', 'fsl timeline', 'fsl add',
>>'fsl rm', 'fsl addremove'
>>
>> You can see a summary of these definitions using the `fsl wrapper'
>> pseudo-command:
>>
>>   $ fsl wrapper
>>   Aliases: . d , log heads
>>   Filters: changes status timeline add rm addremove leaves d
>>
>> The configuration file is a Tcl script: you can define `proc's (for
>> helper functions) and employ them in your filters. Definitions will
>> end up in the `config::fslrc' namespace so you needn't worry about
>> clobbering predefined functions. Since the script makes heavy use of
>> dictionaries, it requires Tcl >= 8.5.
>>
>> Alias declarations are trivial; their second argument can be a
>> bareword or quoted string, thereby allowing expansions to provide
>> switches if required, e.g.
>>
>>   alias log  timeline
>>   alias history {timeline -n 100}
>>
>> Filters are named, allowing them to be referenced elsewhere in your
>> configuration script. Their structure is:
>>
>>   filter   
>>
>> If you filter on a fossil command like `diff', aliases of this command
>> (by default, `d') will also be filtered. Conversely, filtering on an
>> alias (`d'), leaves its expansion (`diff') untouched. Also note that
>> more than one filter may apply to a given command: under the default
>> configuration, the timeline will be filtered by both `status' and
>> `log_entry'.
>>
>> A filter body can reference the current output line via the implicitly
>> defined $line variable. By way of example, here's the `log_entry'
>> filter:
>>
>>   filter log_entry {leaves timeline} {
>>   if {[regexp "^=== .* ===" $line]} {
>>   coloured blue $line
>>   } else {
>>   regsub -all {\[[A-Fa-f0-9]+\]} $line [coloured yellow &]
>>   }
>>   }
>>
>> Useful functions defined by the script are:
>>
>>* `coloured' (for colouring output)
>>* `alias?'
>>* `filter?'
>>* `empty?' and `prefix?' (simple utility functions)
>>
>> Patches, criticisms, suggestions etc. are welcome.
>>
>> Best,
>> Marc
>>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> __**_
> fossil-users mailing list
> fossil-users@lists.fossil-scm.**org 
> http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users
>
___
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] (Another?) fossil wrapper script

[j. v. d. hoff]

thanks for this script which looks promising.
first bug report: I see interference with the `nano' editor (which is set  
as my 'checkin editor' due to its low latency): `nano' is keyboard driven  
and uses the command `^X' (CNTRL-X) for "save and exit". when using `fsl  
ci' the editor opens all right and I can enter the commit message. CNTRL-X  
however is not recognized as a command any more but rather is taken as  
verbatim input: no way to leave the editor except killing the window. this  
does happen only when issuing `fsl ci'

`fossil ci' behaves as expected.

regards,
joerg


On Tue, 11 Dec 2012 11:46:37 +0100, Marc Simpson  wrote:


Hi all,

I've recently written a simple wrapper for Fossil with the goal of
providing an improved CLI experience and thought others might find it
useful.

The script is written in Tcl/Expect and provides the following features:

   * Command aliasing
   * Output filtering
   * A number of preconfigured aliases, filters for colouring output

Though still inchoate, you should be able to use it as you would
`fossil' on the command line.

If you're interested, feel free to clone from
http://fossil.0branch.com/fsl/home or download `fsl' directly:
http://fossil.0branch.com/fsl/artifact/f57c7ecf8c4db2a9990b40ee21e7637a1374f45e
.
The code is ISC licensed (likely overkill for such a simple script).

# Details

Out of the box, a number of filters and aliases are defined in
~/.fslrc (created on first run):

   * Aliases ('->' indicates the expansion)
  * '.' -> 'changes'
  * 'd' -> 'diff'
  * ',' -> 'ui'
  * 'log'   -> 'timeline'
  * 'heads' -> 'leaves'

   * Filters (all of which colour output)
  * 'diff'
 * 'fsl d'
  * 'log_entry'
 * 'fsl leaves', 'fsl timeline'
  * 'status'
 * 'fsl changes', 'fsl status', 'fsl timeline', 'fsl add',
   'fsl rm', 'fsl addremove'

You can see a summary of these definitions using the `fsl wrapper'
pseudo-command:

  $ fsl wrapper
  Aliases: . d , log heads
  Filters: changes status timeline add rm addremove leaves d

The configuration file is a Tcl script: you can define `proc's (for
helper functions) and employ them in your filters. Definitions will
end up in the `config::fslrc' namespace so you needn't worry about
clobbering predefined functions. Since the script makes heavy use of
dictionaries, it requires Tcl >= 8.5.

Alias declarations are trivial; their second argument can be a
bareword or quoted string, thereby allowing expansions to provide
switches if required, e.g.

  alias log  timeline
  alias history {timeline -n 100}

Filters are named, allowing them to be referenced elsewhere in your
configuration script. Their structure is:

  filter   

If you filter on a fossil command like `diff', aliases of this command
(by default, `d') will also be filtered. Conversely, filtering on an
alias (`d'), leaves its expansion (`diff') untouched. Also note that
more than one filter may apply to a given command: under the default
configuration, the timeline will be filtered by both `status' and
`log_entry'.

A filter body can reference the current output line via the implicitly
defined $line variable. By way of example, here's the `log_entry'
filter:

  filter log_entry {leaves timeline} {
  if {[regexp "^=== .* ===" $line]} {
  coloured blue $line
  } else {
  regsub -all {\[[A-Fa-f0-9]+\]} $line [coloured yellow &]
  }
  }

Useful functions defined by the script are:

   * `coloured' (for colouring output)
   * `alias?'
   * `filter?'
   * `empty?' and `prefix?' (simple utility functions)

Patches, criticisms, suggestions etc. are welcome.

Best,
Marc



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] (Another?) fossil wrapper script

[Marc Simpson]

Hi all,

I've recently written a simple wrapper for Fossil with the goal of
providing an improved CLI experience and thought others might find it
useful.

The script is written in Tcl/Expect and provides the following features:

   * Command aliasing
   * Output filtering
   * A number of preconfigured aliases, filters for colouring output

Though still inchoate, you should be able to use it as you would
`fossil' on the command line.

If you're interested, feel free to clone from
http://fossil.0branch.com/fsl/home or download `fsl' directly:
http://fossil.0branch.com/fsl/artifact/f57c7ecf8c4db2a9990b40ee21e7637a1374f45e
.
The code is ISC licensed (likely overkill for such a simple script).

# Details

Out of the box, a number of filters and aliases are defined in
~/.fslrc (created on first run):

   * Aliases ('->' indicates the expansion)
  * '.' -> 'changes'
  * 'd' -> 'diff'
  * ',' -> 'ui'
  * 'log'   -> 'timeline'
  * 'heads' -> 'leaves'

   * Filters (all of which colour output)
  * 'diff'
 * 'fsl d'
  * 'log_entry'
 * 'fsl leaves', 'fsl timeline'
  * 'status'
 * 'fsl changes', 'fsl status', 'fsl timeline', 'fsl add',
   'fsl rm', 'fsl addremove'

You can see a summary of these definitions using the `fsl wrapper'
pseudo-command:

  $ fsl wrapper
  Aliases: . d , log heads
  Filters: changes status timeline add rm addremove leaves d

The configuration file is a Tcl script: you can define `proc's (for
helper functions) and employ them in your filters. Definitions will
end up in the `config::fslrc' namespace so you needn't worry about
clobbering predefined functions. Since the script makes heavy use of
dictionaries, it requires Tcl >= 8.5.

Alias declarations are trivial; their second argument can be a
bareword or quoted string, thereby allowing expansions to provide
switches if required, e.g.

  alias log  timeline
  alias history {timeline -n 100}

Filters are named, allowing them to be referenced elsewhere in your
configuration script. Their structure is:

  filter   

If you filter on a fossil command like `diff', aliases of this command
(by default, `d') will also be filtered. Conversely, filtering on an
alias (`d'), leaves its expansion (`diff') untouched. Also note that
more than one filter may apply to a given command: under the default
configuration, the timeline will be filtered by both `status' and
`log_entry'.

A filter body can reference the current output line via the implicitly
defined $line variable. By way of example, here's the `log_entry'
filter:

  filter log_entry {leaves timeline} {
  if {[regexp "^=== .* ===" $line]} {
  coloured blue $line
  } else {
  regsub -all {\[[A-Fa-f0-9]+\]} $line [coloured yellow &]
  }
  }

Useful functions defined by the script are:

   * `coloured' (for colouring output)
   * `alias?'
   * `filter?'
   * `empty?' and `prefix?' (simple utility functions)

Patches, criticisms, suggestions etc. are welcome.

Best,
Marc
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users