Re: [fossil-users] Why Hash

[j. van den hoff]

On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal   
wrote:



On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein 
wrote:


On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
veedeeh...@googlemail.com> wrote:


in a breach of promise to myself to never again argue in favour of this
functionality on the fossil mailing list (it came up a few times over  
the

last years):


If I understand correctly, the way fossil is designed could cause the
numbers to change *even locally* upon a rebuild, or even just a sync.  
This

would probably get confusing.



Correct. And if i'm not mistaken, if you rebuild with the --randomize
option then the order could get even weirder.


well, I'm only talking about the ordinal numbers chronologically  
enumerating the timeline checkin(!) entries. this enumeration will not  
change as a consequence of rebuild, right? it might change after a sync  
against some remote repo if there are incoming checkins chronologically  
interleaved with my own, sure, but so what? the relative numbers would be  
just a (somewhat "volatile") convenience measure _locally_. and I agree  
with another recent post that this would primarily concern the CLI. what I  
mean: go ask some hg users when they last did use sha1 hashes for  
specifying checkins in their interaction with hg (which supports both the  
ordinals as well as the hashes for doing so) and how often the presence of  
those numbers confused communication with other developers in their  
project. I'm quite sure they _never_ specify sha1 hashes to denote  
checkins in any small to medium-sized project  below 10^4 checkins  
(currently
this still includes fossil itself). not so sure about the "communication"  
issue if users forget the potentially 'volatile' nature of the relative  
enumeration, but this just can't possibly be a big issue ...


I therefore just maintain it would be "nice to have". it sure ain't a  
killer feature, I admit ...




(@Joerg: i was trying to remember who it was who used to ask for this
feature ;)


I plead guilty ;-). and will now keep quite again regarding this issue 






--
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] Feature request: FOSSIL ALL CLOSE

[Tony Papadimitriou]

Is it possible to have an ‘FOSSIL ALL CLOSE’ command?

I usually have several unrelated fossils open at once.  And because of working 
on the same ones from work and home (and sometimes notebook), and how I 
transfer backups back and forth at the end of the day, I *need* to close all 
open fossils, but sometimes I forget which ones I had opened, so I have to go 
to each directory and check with something like ‘FOSSIL CHA’ to get the message 
“current directory is not within an open checkout” if the fossil is already 
closed, or else do a “FOSSIL CLOSE”.

I thought it would much simpler if I could just issue a “FOSSIL ALL CLOSE” 
command.

Thanks.

P.S. I know many people don’t bother closing the fossil at all.  However, I 
find the alternative of pushing to a USB drive not convenient when the same 
fossil needs to also be pushed on a local server not reachable from the 
Internet.  So, since the push settings can either point to the USB or the 
server, it’s much simpler to just backup the whole fossil file.___
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 Hash

[Jacek Cała]

2015-09-09 22:03 GMT+01:00 paul :

> On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari 
> wrote:
>
>>
 Assuming I am remembering correctly, if Fossil had this feature, you
>>> could
>>> do something like:
>>>
>>> $ fossil timeline -N -n 3
>>> 0  [d28be5063a] *CURRENT* Fix linker parameter file
>>> 1  [10a5af61c1] Alt code for HS interface
>>> 2  [5250e3796e] Increase speed threshold
>>> $ fossil info 1
>>> uuid: 10a5af61c1fc25060ad428de9c82e3615b45f6c8 ...
>>>
>>> The numbers, of course, could change after any sync or commit.
>>>
>>

> Sounds to me like you need a GUI.
>>
>
> Some things are just more convenient with a GUI.
>
>
Personally, I don't think it is only the GUI thing. Fossil delivers both
sides: the CLI client and the server in a neat single exec file. The
ordered numbering is just a client-side convenience. Long time ago I was
trying to propose and (almost) implemented numbering for changes, so you
could do selective commit with range of files like 1-5,7. There was little
interest in that feature, so I gave up.

All in all, I think it would be nice to add these little things to the
console client, so the need for the GUI is only for those who really hate
console.

  Cheers,
  Jacek
___
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 Hash

[Michal Suchanek]

On 10 September 2015 at 15:17, j. van den hoff
 wrote:
> On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal 
> wrote:
>
>> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein 
>> wrote:
>>
>>> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
>>> veedeeh...@googlemail.com> wrote:
>>>
 in a breach of promise to myself to never again argue in favour of this
 functionality on the fossil mailing list (it came up a few times over
 the
 last years):
>>>
>>>
>>> If I understand correctly, the way fossil is designed could cause the
>>> numbers to change *even locally* upon a rebuild, or even just a sync.
>>> This
>>> would probably get confusing.
>>>
>>
>> Correct. And if i'm not mistaken, if you rebuild with the --randomize
>> option then the order could get even weirder.
>
>
> well, I'm only talking about the ordinal numbers chronologically enumerating
> the timeline checkin(!) entries. this enumeration will not change as a
> consequence of rebuild, right? it might change after a sync against some
> remote repo if there are incoming checkins chronologically interleaved with
> my own, sure, but so what? the relative numbers would be just a (somewhat
> "volatile") convenience measure _locally_. and I agree with another recent
> post that this would primarily concern the CLI. what I mean: go ask some hg
> users when they last did use sha1 hashes for specifying checkins in their
> interaction with hg (which supports both the ordinals as well as the hashes
> for doing so) and how often the presence of those numbers confused
> communication with other developers in their project. I'm quite sure they
> _never_ specify sha1 hashes to denote checkins in any small to medium-sized
> project  below 10^4 checkins (currently
> this still includes fossil itself). not so sure about the "communication"
> issue if users forget the potentially 'volatile' nature of the relative
> enumeration, but this just can't possibly be a big issue ...
>
> I therefore just maintain it would be "nice to have". it sure ain't a killer
> feature, I admit ...
>

Given that fossil does not support history rewriting by design the
commit number on a particular branch counting from root is unique and
stable per branch across all repos.

If you release from a single master branch you have a monotonous
snapshot number.

When you use multiple branches you need to add branch name to have
stable unique identifier.

This is not viable eg. for git with rebasing.

Thanks

Michal
___
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 request: FOSSIL ALL CLOSE

[Warren Young]

On Sep 10, 2015, at 8:49 AM, Noam Postavsky  
wrote:
> 
> On Thu, Sep 10, 2015 at 9:33 AM, Tony Papadimitriou  wrote:
>> P.S. I know many people don’t bother closing the fossil at all.  However, 
>> [...]
>> it’s much simpler to just backup the whole fossil file.
> 
> Can't you backup the whole fossil file without closing?

Sure, but you miss out on the things that “close” does:

- Make sure there are no unsaved changes.  Tony may want this as a reminder to 
commit or abandon uncommitted changes at the end of the working day.

- Clear the local stash if you give -f, or warn if there are stashed and 
uncommitted changes otherwise.

- Disassociate the checkout directory from the repository file, so that future 
“all” commands don’t try to use it.

- Remove the .fslckout file.
___
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 Hash

[Ron W]

On Thu, Sep 10, 2015 at 9:17 AM, j. van den hoff 
wrote:
>
> well, I'm only talking about the ordinal numbers chronologically
> enumerating the timeline checkin(!) entries. this enumeration will not
> change as a consequence of rebuild, right? it might change after a sync
> against some remote repo if there are incoming checkins chronologically
> interleaved with my own, sure, but so what? the relative numbers would be
> just a (somewhat "volatile") convenience measure _locally_. and I agree
> with another recent post that this would primarily concern the CLI. what I
> mean: go ask some hg users when they last did use sha1 hashes for
> specifying checkins in their interaction with hg (which supports both the
> ordinals as well as the hashes for doing so) and how often the presence of
> those numbers confused communication with other developers in their
> project. I'm quite sure they _never_ specify sha1 hashes to denote checkins
> in any small to medium-sized project  below 10^4 checkins (currently
> this still includes fossil itself). not so sure about the "communication"
> issue if users forget the potentially 'volatile' nature of the relative
> enumeration, but this just can't possibly be a big issue ...


For the project (a few years ago) I used Hg, yes, for my *local*
interaction with Hg, I did use the sequential numbers to save typing (or
copy/paste) the hashes.

When communicating with others, I used the hash.

In my earlier post, I had misremembered Hg's numbering. I had thought it
was in reverse order. But it is actually in commit order.

Personally, I would find some kind of relative specification more useful.
For example, if I could say "fossil gdiff --from cur-3" and get a diff
between the current check out and the revision 3 commits before the
revision the check out is from - along the same branch. If that would go
beyond the beginning of the branch, then continue back into the "parent"
branch from the branch point.

Revising my  earlier example to more closely reflect this "relative"
concept:

$ fossil timeline -N -n 3
 0  [d28be5063a] *CURRENT* Fix linker parameter file
-1  [10a5af61c1] Alt code for HS interface
-2  [5250e3796e] Increase speed threshold
$ fossil info -r cur-1
uuid: 10a5af61c1fc25060ad428de9c82e3615b45f6c8 ...
___
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 Hash

[Baruch Burstein]

On Thu, Sep 10, 2015 at 1:44 PM, Jacek Cała  wrote:

> All in all, I think it would be nice to add these little things to the
> console client, so the need for the GUI is only for those who really hate
> console.


Some of us (yes, even some programmers) think of it the other way round...


-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
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 request: FOSSIL ALL CLOSE

[Noam Postavsky]

On Thu, Sep 10, 2015 at 9:33 AM, Tony Papadimitriou  wrote:
> P.S. I know many people don’t bother closing the fossil at all.  However, 
> [...]
> it’s much simpler to just backup the whole fossil file.

Can't you backup the whole fossil file without closing?
___
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 request: FOSSIL ALL CLOSE

[Richard Hipp]

On 9/10/15, Tony Papadimitriou  wrote:
>
> P.S. I know many people don’t bother closing the fossil at all.

I don't ever close Fossil repos, for example.

>  However, I
> find the alternative of pushing to a USB drive not convenient when the same
> fossil needs to also be pushed on a local server not reachable from the
> Internet.  So, since the push settings can either point to the USB or the
> server, it’s much simpler to just backup the whole fossil file.

I don't quite understand the problem.  But perhaps you would benefit
from running

fossil setting autosync off --global

when you are off-network, so that your commits do not try to sync.  Then run

fossil setting autosync on --global
fossil all sync

once you are back on-line.

I specifically designed Fossil to make it easier for me to work
off-line and then periodically sync with the network as connectivity
became available.  If you are having difficulty doing the same, that
suggests we need to work on better documentation.

-- 
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

Re: [fossil-users] Why Hash

[paul]

On 10/09/15 14:56, Baruch Burstein wrote:


On Thu, Sep 10, 2015 at 1:44 PM, Jacek Cała > wrote:


All in all, I think it would be nice to add these little things to
the console client, so the need for the GUI is only for those who
really hate console.


Some of us (yes, even some programmers) think of it the other way round...


--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı


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


I mostly use Linux and the command line, but for scm I prefer to use a 
GUI. For Windows, I probably do hate its console :)
___
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 request: FOSSIL ALL CLOSE

[Warren Young]

On Sep 10, 2015, at 7:33 AM, Tony Papadimitriou  wrote:
> 
> Is it possible to have an ‘FOSSIL ALL CLOSE’ command?

The attached patch should work for you.

In my testing here, it chokes when it tries to close a checkout that I have 
since abandoned without properly closing it first, but it sounds like you never 
do that, so this limitation shouldn’t bother you.

Does anyone know how I can make Fossil forget that it once opened myreop.fossil 
in ~/abandoned/directory?  I tried

   fossil all ignore -c ~/abandoned/directory

but it doesn’t help.  My new “fossil all close -f” command continues to try to 
close it, but fails because the directory isn’t there any more.

> P.S. I know many people don’t bother closing the fossil at all.  However, I 
> find the alternative of pushing to a USB drive not convenient when the same 
> fossil needs to also be pushed on a local server not reachable from the 
> Internet.

The option I choose is simply to wait to push until I get back to civilization. 
(Meaning: A place where I can get wifi. :) )

Although Fossil *can* push to two different locations, I only use the optional 
URL parameter to “push” when my canonical central repository gets moved, or 
when the cloned Fossil file gets moved.  It’s a rare operation, not something I 
might expect to do several times a week.

As to your “not reachable from the Internet” comment, VPN technology is 
rock-solid these days.  It is quite possible to attach your remote laptop to 
the internal LAN, with security adequate for almost any normal purpose.  (i.e. 
Don’t use a VPN to allow remote access to a nuclear missile silo.)

If you’re worried about the security of your LAN with VPN access allowed, 
you’re probably worrying about the wrong threat.  I’d be more worried about 
losing that presumably-unencrypted USB key, for one thing.

If you don’t like VPNs, sshd configured to accept only keys, and listening on a 
nonstandard port, possibly obscured with port-knocking would also work.  You 
can tunnel arbitrary ports through SSH, creating a kind of “lite” VPN.



fossil-all-close.patch
Description: Binary data
___
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 Hash

[Michal Suchanek]

On 10 September 2015 at 16:54, Martin Gagnon  wrote:
> On Thu, Sep 10, 2015 at 03:29:24PM +0200, Michal Suchanek wrote:
>> On 10 September 2015 at 15:17, j. van den hoff
>>  wrote:
>> > On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal 
>> > wrote:
>> >
>> >> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein 
>> >> wrote:
>> >>
>> >>> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
>> >>> veedeeh...@googlemail.com> wrote:
>> >>>
>>  in a breach of promise to myself to never again argue in favour of this
>>  functionality on the fossil mailing list (it came up a few times over
>>  the
>>  last years):
>> >>>
>> >>>
>> >>> If I understand correctly, the way fossil is designed could cause the
>> >>> numbers to change *even locally* upon a rebuild, or even just a sync.
>> >>> This
>> >>> would probably get confusing.
>> >>>
>> >>
>> >> Correct. And if i'm not mistaken, if you rebuild with the --randomize
>> >> option then the order could get even weirder.
>> >
>> >
>> > well, I'm only talking about the ordinal numbers chronologically 
>> > enumerating
>> > the timeline checkin(!) entries. this enumeration will not change as a
>> > consequence of rebuild, right? it might change after a sync against some
>> > remote repo if there are incoming checkins chronologically interleaved with
>> > my own, sure, but so what? the relative numbers would be just a (somewhat
>> > "volatile") convenience measure _locally_. and I agree with another recent
>> > post that this would primarily concern the CLI. what I mean: go ask some hg
>> > users when they last did use sha1 hashes for specifying checkins in their
>> > interaction with hg (which supports both the ordinals as well as the hashes
>> > for doing so) and how often the presence of those numbers confused
>> > communication with other developers in their project. I'm quite sure they
>> > _never_ specify sha1 hashes to denote checkins in any small to medium-sized
>> > project  below 10^4 checkins (currently
>> > this still includes fossil itself). not so sure about the "communication"
>> > issue if users forget the potentially 'volatile' nature of the relative
>> > enumeration, but this just can't possibly be a big issue ...
>> >
>> > I therefore just maintain it would be "nice to have". it sure ain't a 
>> > killer
>> > feature, I admit ...
>> >
>>
>> Given that fossil does not support history rewriting by design the
>> commit number on a particular branch counting from root is unique and
>> stable per branch across all repos.
>>
>> If you release from a single master branch you have a monotonous
>> snapshot number.
>>
>> When you use multiple branches you need to add branch name to have
>> stable unique identifier.
>>
>> This is not viable eg. for git with rebasing.
>
> Even in fossil it could be a problem, it cannot re-write history but a
> branch is just a tag that can change. The identifier will change
> after moving checkins on a branch.
>

If you can remove the tag that denotes the branch name from a branch
and put it on another branch then the repo-unique identifiers will
change since the branch name part will change, of course. The
branch-unique identifier is stable, however. It can for example denote
commits on currently checked out branch fine.

And even with the ability to rename branches the branch name+commit
number identifier is unique at any given time. Just not stable wrt
branch rename which is understandable.

Thanks

Michal
___
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 Hash

[Martin Gagnon]

On Thu, Sep 10, 2015 at 03:29:24PM +0200, Michal Suchanek wrote:
> On 10 September 2015 at 15:17, j. van den hoff
>  wrote:
> > On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal 
> > wrote:
> >
> >> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein 
> >> wrote:
> >>
> >>> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
> >>> veedeeh...@googlemail.com> wrote:
> >>>
>  in a breach of promise to myself to never again argue in favour of this
>  functionality on the fossil mailing list (it came up a few times over
>  the
>  last years):
> >>>
> >>>
> >>> If I understand correctly, the way fossil is designed could cause the
> >>> numbers to change *even locally* upon a rebuild, or even just a sync.
> >>> This
> >>> would probably get confusing.
> >>>
> >>
> >> Correct. And if i'm not mistaken, if you rebuild with the --randomize
> >> option then the order could get even weirder.
> >
> >
> > well, I'm only talking about the ordinal numbers chronologically enumerating
> > the timeline checkin(!) entries. this enumeration will not change as a
> > consequence of rebuild, right? it might change after a sync against some
> > remote repo if there are incoming checkins chronologically interleaved with
> > my own, sure, but so what? the relative numbers would be just a (somewhat
> > "volatile") convenience measure _locally_. and I agree with another recent
> > post that this would primarily concern the CLI. what I mean: go ask some hg
> > users when they last did use sha1 hashes for specifying checkins in their
> > interaction with hg (which supports both the ordinals as well as the hashes
> > for doing so) and how often the presence of those numbers confused
> > communication with other developers in their project. I'm quite sure they
> > _never_ specify sha1 hashes to denote checkins in any small to medium-sized
> > project  below 10^4 checkins (currently
> > this still includes fossil itself). not so sure about the "communication"
> > issue if users forget the potentially 'volatile' nature of the relative
> > enumeration, but this just can't possibly be a big issue ...
> >
> > I therefore just maintain it would be "nice to have". it sure ain't a killer
> > feature, I admit ...
> >
> 
> Given that fossil does not support history rewriting by design the
> commit number on a particular branch counting from root is unique and
> stable per branch across all repos.
> 
> If you release from a single master branch you have a monotonous
> snapshot number.
> 
> When you use multiple branches you need to add branch name to have
> stable unique identifier.
> 
> This is not viable eg. for git with rebasing.

Even in fossil it could be a problem, it cannot re-write history but a
branch is just a tag that can change. The identifier will change
after moving checkins on a branch.

-- 
Martin G.
___
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 Hash

[Konstantin Khomoutov]

On Thu, 10 Sep 2015 11:29:15 -0400
Ron W  wrote:

[...]
> Personally, I would find some kind of relative specification more
> useful. For example, if I could say "fossil gdiff --from cur-3" and
> get a diff between the current check out and the revision 3 commits
> before the revision the check out is from - along the same branch.

That's what Git does (see ^N and ~N revision suffixes) [1].
Actually, its revision modifiers can do way more than that.

Mercurial's revsets [2] are also quite powerful.

1. https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
2. http://hg.intevation.org/mercurial/crew/file/tip/mercurial/help/revsets.txt
___
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 Hash

[Noam Postavsky]

On Thu, Sep 10, 2015 at 9:29 AM, Michal Suchanek  wrote:
> Given that fossil does not support history rewriting by design the
> commit number on a particular branch counting from root is unique and
> stable per branch across all repos.
>
> If you release from a single master branch you have a monotonous
> snapshot number.
>
> When you use multiple branches you need to add branch name to have
> stable unique identifier.
>
> This is not viable eg. for git with rebasing.

I think (accidental) forks in fossil would also break the uniqueness
of the numbering scheme.

For example see figure 3 of
http://fossil-scm.org/xfer/doc/trunk/www/branching.wiki

Both check-ins 3 and 4 are equidistant from the root. More complicated
cases with differing numbers of check-ins on each side of the fork are
possible.
___
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 Hash

[j. van den hoff]

On Thu, 10 Sep 2015 16:54:30 +0200, Martin Gagnon  wrote:


On Thu, Sep 10, 2015 at 03:29:24PM +0200, Michal Suchanek wrote:

On 10 September 2015 at 15:17, j. van den hoff
 wrote:
> On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal  


> wrote:
>
>> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein  


>> wrote:
>>
>>> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
>>> veedeeh...@googlemail.com> wrote:
>>>
 in a breach of promise to myself to never again argue in favour of  
this
 functionality on the fossil mailing list (it came up a few times  
over

 the
 last years):
>>>
>>>
>>> If I understand correctly, the way fossil is designed could cause  
the
>>> numbers to change *even locally* upon a rebuild, or even just a  
sync.

>>> This
>>> would probably get confusing.
>>>
>>
>> Correct. And if i'm not mistaken, if you rebuild with the --randomize
>> option then the order could get even weirder.
>
>
> well, I'm only talking about the ordinal numbers chronologically  
enumerating

> the timeline checkin(!) entries. this enumeration will not change as a
> consequence of rebuild, right? it might change after a sync against  
some
> remote repo if there are incoming checkins chronologically  
interleaved with
> my own, sure, but so what? the relative numbers would be just a  
(somewhat
> "volatile") convenience measure _locally_. and I agree with another  
recent
> post that this would primarily concern the CLI. what I mean: go ask  
some hg
> users when they last did use sha1 hashes for specifying checkins in  
their
> interaction with hg (which supports both the ordinals as well as the  
hashes

> for doing so) and how often the presence of those numbers confused
> communication with other developers in their project. I'm quite sure  
they
> _never_ specify sha1 hashes to denote checkins in any small to  
medium-sized

> project  below 10^4 checkins (currently
> this still includes fossil itself). not so sure about the  
"communication"
> issue if users forget the potentially 'volatile' nature of the  
relative

> enumeration, but this just can't possibly be a big issue ...
>
> I therefore just maintain it would be "nice to have". it sure ain't a  
killer

> feature, I admit ...
>

Given that fossil does not support history rewriting by design the
commit number on a particular branch counting from root is unique and
stable per branch across all repos.

If you release from a single master branch you have a monotonous
snapshot number.

When you use multiple branches you need to add branch name to have
stable unique identifier.

This is not viable eg. for git with rebasing.


Even in fossil it could be a problem, it cannot re-write history but a
branch is just a tag that can change. The identifier will change
after moving checkins on a branch.


is it not much simpler? the timeline of all checkins in any given checkout  
has a well-defined immutable chronological order (as displayed by `fossil  
timeline -t ci': and since fossil knows this order it could easily  
enumerate the checkins just fine...). just enumerating them from "old to  
new" yields the rank/ordinal/sequential number we are talking about that  
might serve as replacement of the hashes for any fossil command where  
those need to be specified. the enumeration just is not unique across  
clones not being completely in sync/identical. but the mapping of these  
numbers to sha1 hashes in _my_ clone (i.e. the sequence of checkins  
displayed in the timeline) of the project might only change (as far as I  
can see) if a sync injects "remote" checkins into the timeline that are  
interleaved with my own (instead of just being "newer" than any of mine).  
that's all. so the mapping `rank <--> sha1' indeed can change (that's why  
the rank cannot completely replace the hashes for uniquely identifying a  
checkin) due to this "chronological interleaving" of checkins in different  
clones of the project. but that's all (the mapping would even be identical  
across all clones being completely in sync at the considered point in  
time). and it really is just irrelevant for the simple envisaged  
convenience measure: being able to use the ranks instead of the hashes for  
identifying checkins in _my_ clone when interacting with fossil. but if  
implementing this seems not worth the effort to the devs, so be it.









--
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 Hash

[Martin Gagnon]

On Thu, Sep 10, 2015 at 08:39:49PM +0300, Baruch Burstein wrote:
>On Thu, Sep 10, 2015 at 8:03 PM, j. van den hoff
><[1]veedeeh...@googlemail.com> wrote:
> 
>  and it really is just irrelevant for the simple envisaged convenience
>  measure: being able to use the ranks instead of the hashes for
>  identifying checkins in _my_ clone when interacting with fossil.
> 
>I am starting to agree. When I used hg, I didn't usually even remember the
>local numbers. I would usually look them up in the timeline of recent
>checkins, and then use them for diffs/branches/rollbacks/whatnot. It was
>just easier than hashes. So the renumbering would not be critical.

I agree, but the only *potential* problem would be when people blindly
use the sequential number when posting links on mailing list or forum.
It  could become confusing when the link point to another valid link,
but not the good one.

-- 
Martin G.
___
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 Hash

[Baruch Burstein]

On Thu, Sep 10, 2015 at 8:03 PM, j. van den hoff 
wrote:
>
> and it really is just irrelevant for the simple envisaged convenience
> measure: being able to use the ranks instead of the hashes for identifying
> checkins in _my_ clone when interacting with fossil.


I am starting to agree. When I used hg, I didn't usually even remember the
local numbers. I would usually look them up in the timeline of recent
checkins, and then use them for diffs/branches/rollbacks/whatnot. It was
just easier than hashes. So the renumbering would not be critical.


-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
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 Hash

[Ross Berteig]

On 9/10/2015 3:44 AM, Jacek Cała wrote:

 Long time ago I was
trying to propose and (almost) implemented numbering for changes, so you
could do selective commit with range of files like 1-5,7. There was
little interest in that feature, so I gave up.

All in all, I think it would be nice to add these little things to the
console client, so the need for the GUI is only for those who really
hate console.


I realized mid change the other day that the repo I was in had a bunch 
of IDE private project data files that had been checked in. (Rant: Just 
when will IDE authors learn to prominently document their project 
databases to make interoperation with any VCS easier?)


I've learned to take care of that sort of housekeeping when I notice it, 
so I went and did fossil rm (and fixed ignore-glob) to nip them off. 
Then I had a current checkout where fossil changes listed the eight 
files marked DELETED, an ADDED line for ignore-glob (apparently I hadn't 
really set this repo up right yet), and four EDITED for the actual change.


I've never been certain how to checkin just a delete, rename or merge, 
so the easy answer in this case was to remember that the stash exists 
and use that to hold the real work for a minute or two while I checked 
in the structural changes.


But numbering the output of fossil changes with simple ordinals that can 
be used by an "immediately following" fossil commit would have been a 
clear and direct way of saying that to the command line. Those ordinals 
would have to be really transient, and likely are invalidated by nearly 
anything that changes a file, but for that specific sequence of fossil 
changes then fossil ci it could be friendly.


But the stash worked for me, and was in some sense safer because once 
the right files were stashed, I couldn't accidentally mix them into any 
checkin until they were popped back out.


--
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] Why Hash

[Ron W]

On Thu, Sep 10, 2015 at 2:30 PM, Ross Berteig  wrote:
>
> I realized mid change the other day that the repo I was in had a bunch of
> IDE private project data files that had been checked in. (Rant: Just when
> will IDE authors learn to prominently document their project databases to
> make interoperation with any VCS easier?)
>

You mean so you more easily ignore or mark them as "binary"?

Fossil itself has no IDE integration features.

But numbering the output of fossil changes with simple ordinals that can be
> used by an "immediately following" fossil commit would have been a clear
> and direct way of saying that to the command line. Those ordinals would
> have to be really transient,


Which is why I like the idea of relative specifications like "cur-3",
"cur+2" or "tip-1"


> and likely are invalidated by nearly anything that changes a file, but for
> that specific sequence of fossil changes then fossil ci it could be
> friendly.
___
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 Hash

[Stephan Beal]

On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein 
wrote:

> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
> veedeeh...@googlemail.com> wrote:
>
>> in a breach of promise to myself to never again argue in favour of this
>> functionality on the fossil mailing list (it came up a few times over the
>> last years):
>
> If I understand correctly, the way fossil is designed could cause the
> numbers to change *even locally* upon a rebuild, or even just a sync. This
> would probably get confusing.
>

Correct. And if i'm not mistaken, if you rebuild with the --randomize
option then the order could get even weirder.

(@Joerg: i was trying to remember who it was who used to ask for this
feature ;)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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 Hash

[j. van den hoff]

On Thu, 10 Sep 2015 20:16:52 +0200, Martin Gagnon  wrote:


On Thu, Sep 10, 2015 at 08:39:49PM +0300, Baruch Burstein wrote:

   On Thu, Sep 10, 2015 at 8:03 PM, j. van den hoff
   <[1]veedeeh...@googlemail.com> wrote:

 and it really is just irrelevant for the simple envisaged  
convenience

 measure: being able to use the ranks instead of the hashes for
 identifying checkins in _my_ clone when interacting with fossil.

   I am starting to agree. When I used hg, I didn't usually even  
remember the

   local numbers. I would usually look them up in the timeline of recent
   checkins, and then use them for diffs/branches/rollbacks/whatnot. It  
was

   just easier than hashes. So the renumbering would not be critical.


I agree, but the only *potential* problem would be when people blindly
use the sequential number when posting links on mailing list or forum.
It  could become confusing when the link point to another valid link,
but not the good one.


yes, beyond "checkin 1000" this could happen (if by chance there is some  
checkin whose sha1 hash starts with those 4 digits). but I would argue  
that when posting links or talking about checkins on mailing lists it  
simply should be considered mandatory to use the hashes. should not be  
_that_ much of a pedagogical challenge to drive that point home ;-)







--
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