Re: [fossil-users] Behavior of rm, mv, and changes/extra

[Bob Chapman]

> Not everyone uses Unix.
> Are there Windows shells supporting aliases, outside of 'mingw/bash' ?

It's not free but I find JP Software's Take Command (TCMD) and Take
Command Console (TCC) indispensable. 

--
___
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] Behavior of rm, mv, and changes/extra

[Christopher Berardi]

On Tue, Feb 28, 2012 at 03:04:22PM -0800, Andreas Kupries wrote:
> On 2/28/2012 3:03 PM, Christopher Berardi wrote:
> >On Tue, Feb 28, 2012 at 01:51:29PM +0100, Gour wrote:
> >>c) some aliasing mechanism so that user can create aliases for commands
> >>invoked with common options, e.g, ability to define
> >>
> >>cip = ci --private
> >
> >Why not just use your shell's aliasing mechanism? For example, in a
> >Bourne compatible shell you could place this in your .shrc file:
> > alias cip='fossil ci --private'
> >
> 
> Not everyone uses Unix.
> Are there Windows shells supporting aliases, outside of 'mingw/bash' ?

I think that Windows shortcut links (when they work) allow you to
specify arguments to send. But, Windows isn't really command line
friendly either way.

-- 
Christopher Berardi
http://www.natoufa.com/

May grace and peace by yours in abundance.
___
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] Behavior of rm, mv, and changes/extra

[Ross Berteig]

At 03:04 PM 2/28/2012, Andreas Kupries wrote:

On 2/28/2012 3:03 PM, Christopher Berardi wrote:

On Tue, Feb 28, 2012 at 01:51:29PM +0100, Gour wrote:
c) some aliasing mechanism so that user can create aliases 
for commands

invoked with common options, e.g, ability to define

cip = ci --private


Why not just use your shell's aliasing mechanism? For example, in a
Bourne compatible shell you could place this in your .shrc file:
 alias cip='fossil ci --private'


Not everyone uses Unix.
Are there Windows shells supporting aliases, outside of 
'mingw/bash' ?


Standard Windows Console has aliases. Type DOSKEY /? for
documentation. The suggested alias would be defined by saying:

  DOSKEY cip=fossil ci --private $*

Ideally you'd do this sort of thing in a batch file that you
arrange to invoke when your command prompt launches. My project
specific command-prompt shortcuts all at minimum specify a
starting folder, and often use CMD /K C:\...\CUSTOMERSTART.BAT
as the command line so that the specific batch file is run before
CMD shows its first interactive prompt.

That said, I can see utility for customizing aliases within fossil
itself, so that CIP isn't now a general command but fossil cip does
what the OP wanted. I'm not sure how generally useful this is given
the strength of *nix and Windows aliases and shell scripts, however.

Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

___
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] Tags in web interface vs. "fossil tag list"

[Ron Wilson]

On Tue, Feb 28, 2012 at 5:34 PM, Nolan Darilek  wrote:
> followed the same code path, we'd be golden? Then all other interfaces be
> they command line or JSON could require that you opt into whatever other tag
> types you'd like.

This makes a lot of sense. Not automatically give everything, but do
allow asking for more.
___
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] Behavior of rm, mv, and changes/extra

[Andreas Kupries]

On 2/28/2012 3:03 PM, Christopher Berardi wrote:

On Tue, Feb 28, 2012 at 01:51:29PM +0100, Gour wrote:

c) some aliasing mechanism so that user can create aliases for commands
invoked with common options, e.g, ability to define

cip = ci --private


Why not just use your shell's aliasing mechanism? For example, in a
Bourne compatible shell you could place this in your .shrc file:
 alias cip='fossil ci --private'



Not everyone uses Unix.
Are there Windows shells supporting aliases, outside of 'mingw/bash' ?

--
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™

P: 778.786.1122
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
___
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] Behavior of rm, mv, and changes/extra

[Christopher Berardi]

On Tue, Feb 28, 2012 at 01:51:29PM +0100, Gour wrote:
> c) some aliasing mechanism so that user can create aliases for commands
> invoked with common options, e.g, ability to define 
> 
> cip = ci --private

Why not just use your shell's aliasing mechanism? For example, in a
Bourne compatible shell you could place this in your .shrc file:
alias cip='fossil ci --private'

-- 
Christopher Berardi
http://www.natoufa.com/

May grace and peace by yours in abundance.
___
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] Tags in web interface vs. "fossil tag list"

[Nolan Darilek]

On 02/28/2012 03:36 PM, Stephan Beal wrote:
Amen. Maybe the JSON API should just support a dumbed-down tags 
interface?



So it seems like the command line/web interface would have to use a 
similar tag filter function, right? I mean, they're filtering out these 
various tkt/wiki-/event- tags, and presumably others besides. Maybe if 
everything followed the same code path, we'd be golden? Then all other 
interfaces be they command line or JSON could require that you opt into 
whatever other tag types you'd like.

___
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] Tags in web interface vs. "fossil tag list"

[Stephan Beal]

On Tue, Feb 28, 2012 at 10:28 PM, Nolan Darilek wrote:

>  Huh, the "fossil json tags list" output seems inconsistent with these
> other two:
>

There are several options which
 ...

>
> In particular, it lists wiki pages and events. I'm not sure how those
> qualify as tags,
>

Interestingly enough: a wiki is just an artifact (like a file) with a
special tag wiki-PageName. Each ticket has a tag named tkt-TICKET_UUID.


> either via the web or command line interfaces. Not being critical, I'm
> just genuinely confused
>

LOL! You're not the only one. After doing the initial json tags interface i
said, "huh?" Note the yellow-marked text in the docs which make note of how
confusing/inconsistent the interface is (at least in the context of a JSON
API). The impl was based directly on code (mainly queries) from the HTML
interface, which is why it uses the formats/options it does. i'd like to
change some of it, in any case, and i'm open to concrete suggestions.

belt ninja tag" or something. Seriously, tags are confusing when you get
> beyond the basics.
>

Amen. Maybe the JSON API should just support a dumbed-down tags interface?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Tags in web interface vs. "fossil tag list"

[Nolan Darilek]

Huh, the "fossil json tags list" output seems inconsistent with these 
other two:


{
"fossil":"aa55cf3aa6d4c74c781c1c8d2f9b0807c3a2740c",
"timestamp":1330464343,
"command":"tag/list",
"procTimeMs":1,
"payload":{
"raw":false,
"includeTickets":false,
"tags":[
"branch",
"closed",
"cluster",
"comment",
"date",
"event-2bc72955fd5f251cf783d3729b1fb9e84fc7138b",
"event-66cb21a5ab54ee8598b681bf98aafabc1ba4ec87",
"event-7f1513705b86e8e7292b83078b22e04bf333cdd4",
"event-c0395a4f0df7991135418b51a510c39e43508cf4",
"event-df0658580af71cbfc4e63926ad747187f13bef43",
"event-f37029d1ca46c9d9d9b5afbc9a778b05a0f54a00",
"0.8",
"0.9.0rc1",
"0.9.0rc2",
"1.0.0",
"1.0.1",
"1.1.0",
"1.1.1",
"1.1.2",
"1.1.3",
"master",
"release",
"review",
"scripting",
"trunk",
"wiki-Spiel",
"wiki-download",
"wiki-faq",
"wiki-features",
"wiki-release-notes-template",
"wiki-source"
]
}
}

In particular, it lists wiki pages and events. I'm not sure how those 
qualify as tags, unless tags are how URLs are resolved to artifacts, but 
those tags aren't reported either via the web or command line 
interfaces. Not being critical, I'm just genuinely confused, and think 
this is why consistency would be useful. If a tag is visible in all 
interfaces, we should be able to say "that's because it's a 
non-propagating third degree black belt ninja tag" or something. 
Seriously, tags are confusing when you get beyond the basics.



On 02/28/2012 03:19 PM, Stephan Beal wrote:
On Tue, Feb 28, 2012 at 9:40 PM, Nolan Darilek > wrote:


I'm wondering if what I get with "fossil tag list" might be
brought in sync with what I get from the web interface, since that
is a more useful list of tags for my project?


FWIW: the JSON API's tags interface offers all or most of the options 
supported by the HTML interface. That said, i personally find it 
difficult to remember all the different options and the ways they 
interact (and change the response structure), and the current 
interface is open to suggestions and up for debate:


https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?pli=1#heading=h.h1ag4m728xv5

i'd especially like to hear from those who make heavy use of tags (i 
don't).


stephan@tiny:~/cvs/fossil/fossil$ f json tag
{
"fossil":"affb0019c9068467a6fe7cfbc76d0ca233721be3",
"timestamp":1330463892,
"resultCode":"FOSSIL-3002",
"resultText":"No subcommand specified. Try one of (add, cancel, find, 
list).",

"command":"tag",
"procTimeMs":4
}


--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal



___
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] Tags in web interface vs. "fossil tag list"

[Stephan Beal]

On Tue, Feb 28, 2012 at 9:40 PM, Nolan Darilek wrote:

> I'm wondering if what I get with "fossil tag list" might be brought in
> sync with what I get from the web interface, since that is a more useful
> list of tags for my project?
>

FWIW: the JSON API's tags interface offers all or most of the options
supported by the HTML interface. That said, i personally find it difficult
to remember all the different options and the ways they interact (and
change the response structure), and the current interface is open to
suggestions and up for debate:

https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?pli=1#heading=h.h1ag4m728xv5

i'd especially like to hear from those who make heavy use of tags (i don't).

stephan@tiny:~/cvs/fossil/fossil$ f json tag
{
"fossil":"affb0019c9068467a6fe7cfbc76d0ca233721be3",
"timestamp":1330463892,
"resultCode":"FOSSIL-3002",
"resultText":"No subcommand specified. Try one of (add, cancel, find,
list).",
"command":"tag",
"procTimeMs":4
}


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] assign ticket to file(s) or abusing Fossil a bit

[Stephan Beal]

On Tue, Feb 28, 2012 at 9:19 PM, Ron Wilson  wrote:

> function as a link to the ticket. (This also works with "embedded
> document" wiki pages, but updating embedded document pages with the
> Fossil UI is not (yet) possible.)
>

FWIW: committing embedded docs via the JSON API is on the TODO list. i
_think_ it can be done without any internals-level refactoring but i have
not yet looked closely at it.


> Using some combination of TH1 and Javascript, the link to a new ticket
> can be appended to a wiki, automatically, when the ticket is
> created.


Wiki pages can be created/edited via the JSON interface. Ticket handling is
still on the TODO list.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Tags in web interface vs. "fossil tag list"

[Nolan Darilek]

I notice that, when I do "fossil tag list", I get a list of all tags 
including some that are non-propagating and closed. When I visit the 
Tags screen from the web interface, I get what I'd expect to see when 
listing tags. In particular, I have a tag for each released version, 
including "trunk". I have some other tags for features I started 
developing, or major changes I made in a specific topic, but that I've 
since closed and abandoned.


I'm wondering if what I get with "fossil tag list" might be brought in 
sync with what I get from the web interface, since that is a more useful 
list of tags for my project?
For an example of what I mean, check out the repository at 
http://spielproject.info. The web-based list of tags are exactly what I 
want, but "fossil tag list" gives me a bunch of useless tags from old 
topics I'm finished with. Maybe that can be shown with an "--all" argument?


Thanks.
___
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] assign ticket to file(s) or abusing Fossil a bit

[Ron Wilson]

On Sun, Feb 26, 2012 at 11:21 AM, Gour  wrote:
> On Sun, 26 Feb 2012 09:25:17 -0400
> Chris Peachment  wrote:
>
>> It looks to me like you could add a new field to the 'ticket' table,
>
>> The missing part is some way to pass the patient id to the report so
>> that it selects only tickets for the given patient.
>
>> You might need to hack the report menu source code to permit entry of
>> one (or more) parameters when the report is selected.
>
> Huh...my C skills are rusty and I hoped I could do without surgery
> 'cause otherwise tweaking Roundup tracker might be easisier solution.
>
> Let's see if there is some other idea.

I am reasonably sure it can be done with out "C surgery". (However, a
proper search feature for tickets should be added to Fossil.)

Use Fossil wiki pages for the "master" patient files. (the "built in"
wiki pages).

In a Fossil wiki page, a ticket id enclosed between [ and ] will
function as a link to the ticket. (This also works with "embedded
document" wiki pages, but updating embedded document pages with the
Fossil UI is not (yet) possible.)

Using some combination of TH1 and Javascript, the link to a new ticket
can be appended to a wiki, automatically, when the ticket is
created.Actually, this would be done in View Ticket right after the
ticket is forst entered. At that point, the ticket status is New. At
that point, Fossil performs an automatic View Ticket. This is where
the extra processing takes place. A combination of TH1 and Javascript
would see that the status is New and display a Confirm button, along
with a message instructing the user to verify the entered information,
then clinck on Confirm. Javascript would then subimt both a HTTP
request to append [ticketID] to the patient's wiki page, and a HTTP
request to update the ticket status to something other than New.

(probably necessary for the View Ticket of a New ticket to include the
raw wiki page content in a hidden text area that the Javascript would
then append to and submit much like editing a wiki in the Fossil UI.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Failed to commit (new branch) in a closed leaf

[Lluís Batlle i Rossell]

Hello,

at a closed leaf, I try: 
fossil commit -b newbranch

and it tells me it can't work because the leaf is closed. SHouldn't it allow
committing to a new branch, from a closed leaf?

I had to remove the closed tag, and then branch.

Regards,
Lluís.
___
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] Behavior of rm, mv, and changes/extra

[Ramon Ribó]

In fact, the most annoying thing is to go to the files section and
find there files of several years ago that are not used anymore, or
that come from a mistake and they will remain there for years and
years more, making more difficult to review the other files.

The possibility of seeing only the "tip" in that section has somehow
alleviated the problem, but this inconvenient still remains there.

For me, the "all" subsection of the "files" section should contain all
the files of current and previous releases that we have not explicitly
marked as of no interest anymore. One possible way of doing this would
be to mark some branches as of "no interest" anymore for day to day
work, except for archaeological purposes.


 RR


>
> 2012/2/28 Konstantin Khomoutov :
>> On Tue, 28 Feb 2012 14:47:00 +0100
>> Ramon Ribó  wrote:
>>
>> [...]
>>> (9) in the web page, possibility to mark branches as hidden. It will
>>> be invisible in the timeline, branches section and files section
>>> (files belonging only to hidden branches do not appear), unless a
>>> special option to show hidden is selected. (useful to hide mistakes)
>> Is this really needed?
>> After making a check-in a leaf in the "mistake" branch, close this leaf
>> immediately; this way, the "mistake" branch at any point in time will
>> contain only closed leaves and therefore it will be itself closed and
>> not shown among the active branches.
>>
>> To me, the concept of hidden branches appears to be a misfeature.
___
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] The fdiff page, 'patch' mode, has html

[Lluís Batlle i Rossell]

On Wed, Feb 22, 2012 at 09:51:44AM +0100, Lluís Batlle i Rossell wrote:
> Hello,
> 
> the fdiff page, patch mode, has HTML in it:
> 
> One example:
> http://fossil-scm.org/index.html/fdiff?v1=806340fbc989550a&v2=f1d6ecabf37517e4&patch

Isn't this problem important for a fix? I just write as a reminder...

Regards,
Lluís.
___
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] Behavior of rm, mv, and changes/extra

[Konstantin Khomoutov]

On Tue, 28 Feb 2012 14:47:00 +0100
Ramon Ribó  wrote:

[...]
> (9) in the web page, possibility to mark branches as hidden. It will
> be invisible in the timeline, branches section and files section
> (files belonging only to hidden branches do not appear), unless a
> special option to show hidden is selected. (useful to hide mistakes)
Is this really needed?
After making a check-in a leaf in the "mistake" branch, close this leaf
immediately; this way, the "mistake" branch at any point in time will
contain only closed leaves and therefore it will be itself closed and
not shown among the active branches.

To me, the concept of hidden branches appears to be a misfeature.
___
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] Behavior of rm, mv, and changes/extra

[Leo Razoumov]

On Tue, Feb 28, 2012 at 08:22, Leo Razoumov  wrote:
> On Tue, Feb 28, 2012 at 07:59, Ramon Ribó  wrote:
>>> (1)  "fossil rm" removes the files from the disk
>>> (2)  "fossil mv" renames the files on disk
>>
>> (3)  fossil settings crnl-glob "**"
>> (4)  fossil update == fossil update current
>> (5)  Unlimited undo (purgin old undos after a defined number of days)
>> (6)  Explain in more detail the clock problems with the commit. People do
>>      not understand. Propose solutions
>>
>
>  (7) push/pull individual branches
>  (8) search through wiki pages, timeline, tickets (fossil-scm.org
> branch "exp-search" [1] can be a good start)
>

  (n+1)  ability to scrub individual private branches. Right now
"fossil scrub --private" nukes all private branches at once which IMHO
is an overkill. I would like to be selective of what to remove and
what remains.

--Leo--
___
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] Behavior of rm, mv, and changes/extra

[Altu Faltu]

>>> (1) "fossil rm" removes the files from the disk >>> (2) "fossil mv" renames 
>>> the files on disk >> >> (3) fossil settings crnl-glob "**" >> (4) fossil 
>>> update == fossil update current >> (5) Unlimited undo (purgin old undos 
>>> after a defined number of days) >> (6) Explain in more detail the clock 
>>> problems with the commit. People do >> not understand. Propose solutions >> 
>>> > > (7) push/pull individual branches > (8) search through wiki pages, 
>>> timeline, tickets (fossil-scm.org > branch "exp-search" [1] can be a good 
>>> start) (9) in the web page, possibility to mark branches as hidden. It will 
>>> be invisible in the timeline, branches section and files section (files 
>>> belonging only to hidden branches do not appear), unless a special option 
>>> to show hidden is selected. (useful to hide mistakes) 
 (10) Rebase - Different from git: Keep (and close) the original branch and 
apply all patches from the branch on top of a new base (maintaining commit 
messages). Name of the new branch could be same as old one.
 (11) Export/import of patches that supports file creation/movement/deletion, 
including binary files. May use a custom patch format.
 (12) Rollback / amendment to last commit(s) if not already pushed/pulled.
 (13) Web interface: Multiple sessions per user with option to logout from all 
sessions.
___
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] Behavior of rm, mv, and changes/extra

[Ramon Ribó]

>>> (1)  "fossil rm" removes the files from the disk
>>> (2)  "fossil mv" renames the files on disk
>>
>> (3)  fossil settings crnl-glob "**"
>> (4)  fossil update == fossil update current
>> (5)  Unlimited undo (purgin old undos after a defined number of days)
>> (6)  Explain in more detail the clock problems with the commit. People do
>>      not understand. Propose solutions
>>
>
>  (7) push/pull individual branches
>  (8) search through wiki pages, timeline, tickets (fossil-scm.org
> branch "exp-search" [1] can be a good start)

(9) in the web page, possibility to mark branches as hidden. It will
be invisible in the timeline, branches section and files section
(files belonging only to hidden branches do not appear), unless a
special option to show hidden is selected. (useful to hide mistakes)

RR



2012/2/28 Leo Razoumov :
> On Tue, Feb 28, 2012 at 07:59, Ramon Ribó  wrote:
>>> (1)  "fossil rm" removes the files from the disk
>>> (2)  "fossil mv" renames the files on disk
>>
>> (3)  fossil settings crnl-glob "**"
>> (4)  fossil update == fossil update current
>> (5)  Unlimited undo (purgin old undos after a defined number of days)
>> (6)  Explain in more detail the clock problems with the commit. People do
>>      not understand. Propose solutions
>>
>
>  (7) push/pull individual branches
>  (8) search through wiki pages, timeline, tickets (fossil-scm.org
> branch "exp-search" [1] can be a good start)
>
> [1] http://fossil-scm.org/index.html/timeline?r=exp-search
>
> --Leo--
> ___
> 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] Behavior of rm, mv, and changes/extra

[Konstantin Khomoutov]

On Tue, 28 Feb 2012 08:22:52 -0500
Leo Razoumov  wrote:

> >> (1)  "fossil rm" removes the files from the disk
> >> (2)  "fossil mv" renames the files on disk
> >
> > (3)  fossil settings crnl-glob "**"
> > (4)  fossil update == fossil update current
> > (5)  Unlimited undo (purgin old undos after a defined number of
> > days)
> > (6)  Explain in more detail the clock problems with the commit.
> > People do not understand. Propose solutions
> >
> 
>   (7) push/pull individual branches
>   (8) search through wiki pages, timeline, tickets (fossil-scm.org
>   branch "exp-search" [1] can be a good start)
Anything starting with (3) is not about interface changes but rather
these are feature requests.

I have one feature request which does have something to do with
interface: I'd like to see a set of sensible shortcuts to operate on
tags for common cases, like "make this commit start a branch named
`mistake' (or a leaf of it) and then close this leaf immediately".
Currently fossil has very low-level support for tags accessible from
its command line which require deep level of knowledge about how tags
are organized, what's the deal about symbolic vs raw tags, what are
propagating tags etc--this is all "plumbing" commands (the term borrowed
from Git lingo), and I, as a user, would like to have a set of
higher-level commands to operate branches and leaves.

Yes, I know about web interface (which is cool, no doubts) but I'm often
using fossil while being logged over SSH where using `fossil server` is
technically feasible but requires thinking about establishing SSH
portforwarding up front which is inconvenient.
___
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] Behavior of rm, mv, and changes/extra

[Gour]

On Tue, 28 Feb 2012 08:22:52 -0500
Leo Razoumov  wrote:

>   (8) search through wiki pages, timeline, tickets (fossil-scm.org
> branch "exp-search" [1] can be a good start)

Thank you for this one which I forgot to mention.


Sincerely,
Gour


-- 
Bewildered by the modes of material nature, the ignorant fully 
engage themselves in material activities and become attached. But 
the wise should not unsettle them, although these duties are inferior 
due to the performers' lack of knowledge.

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


signature.asc
Description: PGP signature
___
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] Behavior of rm, mv, and changes/extra

[Leo Razoumov]

On Tue, Feb 28, 2012 at 07:59, Ramon Ribó  wrote:
>> (1)  "fossil rm" removes the files from the disk
>> (2)  "fossil mv" renames the files on disk
>
> (3)  fossil settings crnl-glob "**"
> (4)  fossil update == fossil update current
> (5)  Unlimited undo (purgin old undos after a defined number of days)
> (6)  Explain in more detail the clock problems with the commit. People do
>      not understand. Propose solutions
>

  (7) push/pull individual branches
  (8) search through wiki pages, timeline, tickets (fossil-scm.org
branch "exp-search" [1] can be a good start)

[1] http://fossil-scm.org/index.html/timeline?r=exp-search

--Leo--
___
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] Behavior of rm, mv, and changes/extra

[Ramon Ribó]

> (1)  "fossil rm" removes the files from the disk
> (2)  "fossil mv" renames the files on disk

(3)  fossil settings crnl-glob "**"
(4)  fossil update == fossil update current
(5)  Unlimited undo (purgin old undos after a defined number of days)
(6)  Explain in more detail the clock problems with the commit. People do
  not understand. Propose solutions


RR


2012/2/28 Richard Hipp :
>
>
> On Tue, Feb 28, 2012 at 2:06 AM, Gour  wrote:
>>
>> On Wed, 21 Dec 2011 12:25:19 -0500
>> Richard Hipp  wrote:
>>
>> > I fear to change it now, though, since it might really mess up people
>> > who are used to the older style.
>>
>> What about having something like:
>>
>> fossil rm --force|-f FILE1 FILE2 ...
>>
>> where using '--force' option would make Fossil remove files fromn *both*
>> the project and the disk?
>
>
> I'm leaning more toward Fossil 2.0 that has a number of incompatible changes
> to the command-line interface, such as having "fossil rm" and "fossil mv"
> actually delete and rename the files.  To be clear, the repository file
> format and the sync protocol would continue to be compatible, so Fossil 1.x
> can interact with Fossil 2.x projects.  Only the operation of the various
> "fossil" commands would change, and only in ways that improve the interface,
> based on past experience.
>
> Assuming we go with Fossil 2.0, can somebody propose a list of interface
> changes that are needed.  We don't want to repeat this exercise if it can be
> avoided, so let's fix everything all at once.  Here's a start:
>
> (1)  "fossil rm" removes the files from the disk
> (2)  "fossil mv" renames the files on disk
>
>>
>>
>>
>> Sincerely,
>> Gour
>>
>>
>> --
>> The senses are so strong and impetuous, O Arjuna,
>> that they forcibly carry away the mind even of a man
>> of discrimination who is endeavoring to control them.
>>
>> http://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
>>
>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
> ___
> 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] Behavior of rm, mv, and changes/extra

[Gour]

On Tue, 28 Feb 2012 07:28:11 -0500
Richard Hipp  wrote:

> Assuming we go with Fossil 2.0, can somebody propose a list of
> interface changes that are needed.  We don't want to repeat this
> exercise if it can be avoided, so let's fix everything all at once.
> Here's a start:
> 
> (1)  "fossil rm" removes the files from the disk
> (2)  "fossil mv" renames the files on disk

Those are probably not interface changes, but here are few things I'd
like to see in Fossil 2.0:

a) Rollback for safe usage when one does not do auto-sync or when code is
not pushed out into the wild universe.

b) ability to push/pull single branches

c) some aliasing mechanism so that user can create aliases for commands
invoked with common options, e.g, ability to define 

cip = ci --private


At the moment I cannot think about anything else which I'd like to see
in Fossil to have all desired features presented in a superiorly simple
package. ;)

Stuff like incremental import/export might be handy for those having
need to interoperate with other DVCS-es, but probably it's not so easy
due to design decisions in Fossil.

As far as I am concerned, I'm simply sold on Fossil's simplicity and
will use it for our next open-source project and if 2.0 will solve some
of the a) - c) items, it would be terrific!!!


Sincerely,
Gour


-- 
As a strong wind sweeps away a boat on the water, 
even one of the roaming senses on which the mind 
focuses can carry away a man's intelligence.

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


signature.asc
Description: PGP signature
___
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] Behavior of rm, mv, and changes/extra

[Richard Hipp]

On Tue, Feb 28, 2012 at 2:06 AM, Gour  wrote:

> On Wed, 21 Dec 2011 12:25:19 -0500
> Richard Hipp  wrote:
>
> > I fear to change it now, though, since it might really mess up people
> > who are used to the older style.
>
> What about having something like:
>
> fossil rm --force|-f FILE1 FILE2 ...
>
> where using '--force' option would make Fossil remove files fromn *both*
> the project and the disk?
>

I'm leaning more toward Fossil 2.0 that has a number of incompatible
changes to the command-line interface, such as having "fossil rm" and
"fossil mv" actually delete and rename the files.  To be clear, the
repository file format and the sync protocol would continue to be
compatible, so Fossil 1.x can interact with Fossil 2.x projects.  Only the
operation of the various "fossil" commands would change, and only in ways
that improve the interface, based on past experience.

Assuming we go with Fossil 2.0, can somebody propose a list of interface
changes that are needed.  We don't want to repeat this exercise if it can
be avoided, so let's fix everything all at once.  Here's a start:

(1)  "fossil rm" removes the files from the disk
(2)  "fossil mv" renames the files on disk


>
>
> Sincerely,
> Gour
>
>
> --
> The senses are so strong and impetuous, O Arjuna,
> that they forcibly carry away the mind even of a man
> of discrimination who is endeavoring to control them.
>
> http://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
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users