Re: [fossil-users] Fix for stash-next pointer (fix for the fix)

[Ron W]

On Thu, Aug 18, 2016 at 4:03 PM, Warren Young  wrote:

>
> I don’t argue for this to make git users happy, but instead to make Fossil
> more like Subversion, where there is no additional step required check out
> a new repository.
>

Technically, Fossil checkouts do work (almost) the same way as SVN check
outs:

svn checkout repositoryURL

fossil checkout /repository/path

But, yes, almost every time a local clone of a Fossil repository is made,
the next step is to checkout a working space. So, it would be convenient to
have an option for clone (and init) to automatically checkout a working
space. (Or maybe an option to checkout to auto-clone (or auto-init) a repo.)

But, I do many more checkouts from a local repo than I make clones, so the
extra command the first time isn't an issue for me.
___
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] Fix for stash-next pointer (fix for the fix)

[Scott Robison]

On Thu, Aug 18, 2016 at 2:06 PM, Warren Young  wrote:

> On Aug 17, 2016, at 5:21 PM, Kain Abel  wrote:
> >
> > A former ;) git user would
> > lose the stash without asking if he uses close
>
> You misunderstood my responses above, then.  Fossil tells you that closing
> the repo will remove the stashes, if any are present, and refuses to
> continue unless you pass --force.
>
> This isn’t so much accidentally shooting yourself in the foot as it is
> cocking the hammer taking aim before shooting yourself in the foot. :)
>

Hold on, you mean fossil expects me to read the output to understand the
current state and status of commands issued? That's pretty user
unfriendly...

-- 
Scott Robison
___
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] Fix for stash-next pointer (fix for the fix)

[Warren Young]

On Aug 17, 2016, at 5:21 PM, Kain Abel  wrote:
> 
> A former ;) git user would
> lose the stash without asking if he uses close

You misunderstood my responses above, then.  Fossil tells you that closing the 
repo will remove the stashes, if any are present, and refuses to continue 
unless you pass --force.

This isn’t so much accidentally shooting yourself in the foot as it is cocking 
the hammer taking aim before shooting yourself in the foot. :)
___
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] Fix for stash-next pointer (fix for the fix)

[Warren Young]

On Aug 18, 2016, at 1:12 AM, Stephan Beal  wrote:
> 
> git combines clone/open into a single operation

Fossil could as well.  If you either don’t give a clone target or that target 
is a directory instead of a file, it could save the repo file to .fslrepo or 
similar at the root of either CWD or the clone target directory, then open that 
repo in-place.

> each clone is tied to a single open copy, whereas fossil separates them

That would be one good reason to continue to recommend giving a repo file as 
the second argument to clone instead of using it in git-like fashion.

I don’t argue for this to make git users happy, but instead to make Fossil more 
like Subversion, where there is no additional step required check out a new 
repository.

> i'm guessing that few people ever use 'close’?

I’ve found it useful just prior to rm -r’ing a Fossil checkout for any reason, 
to ensure that Fossil forgets about that checkout.

I recall drh saying that Fossil will eventually realize it has stale info in 
its ~/.fossil repo and forget it, but I’m certain I’ve seen it keep such info 
long past when it should before.  Perhaps that’s been patched now, but ever 
since running into that, I’ve always formally closed a checkout before nuking 
it.
___
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] Fix for stash-next pointer (fix for the fix)

[Kain Abel]

Dear Stephan,

2016-08-18 9:12 GMT+02:00 Stephan Beal:

> i'm guessing that few people ever use 'close'? (i have never - in over 8
> years - used it except when testing fossil.)

In my case very rarely and often with 'close --force' and 'open -keep'.

With regards,
Kain
___
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] Fix for stash-next pointer (fix for the fix)

[Kain Abel]

2016-08-18 9:12 GMT+02:00 Stephan Beal :
> On Thu, Aug 18, 2016 at 1:21 AM, Kain Abel  wrote:
>>
>> Git has no open and close, but also stash.
>
>
> git combines clone/open into a single operation, and each clone is tied to a
> single open copy, whereas fossil separates them: one clone can serve
> multiple local checkouts. The stash information belongs in the checkout, not
> in the clone (otherwise you would see it from all opened checkouts from that
> clone, which would likely just cause confusion).
>
>>
>> A former ;) git user would
>> lose the stash without asking if he uses close (out of whichever
>> reasons) w/o RTfineM. The loss of stashed changes (== working time)
>> could be a disappointment (as an user experience).
>> The key aspect is the loss of information and not the omission of
>> reading the manual.
>
>
> i'm guessing that few people ever use 'close'? (i have never - in over 8
> years - used it except when testing fossil.)
>
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> "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
>
___
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] Fix for stash-next pointer (fix for the fix)

[Stephan Beal]

On Thu, Aug 18, 2016 at 1:21 AM, Kain Abel  wrote:

> Git has no open and close, but also stash.


git combines clone/open into a single operation, and each clone is tied to
a single open copy, whereas fossil separates them: one clone can serve
multiple local checkouts. The stash information belongs in the checkout,
not in the clone (otherwise you would see it from all opened checkouts from
that clone, which would likely just cause confusion).


> A former ;) git user would
> lose the stash without asking if he uses close (out of whichever
> reasons) w/o RTfineM. The loss of stashed changes (== working time)
> could be a disappointment (as an user experience).
> The key aspect is the loss of information and not the omission of
> reading the manual.
>

i'm guessing that few people ever use 'close'? (i have never - in over 8
years - used it except when testing fossil.)


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"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] Fix for stash-next pointer (fix for the fix)

[Kain Abel]

Just a crude thought:

I know, fossil is not git ... but both was designed to preserve
informations and to track their changes. (That is a absolute
simplification.)

Git has no open and close, but also stash. A former ;) git user would
lose the stash without asking if he uses close (out of whichever
reasons) w/o RTfineM. The loss of stashed changes (== working time)
could be a disappointment (as an user experience).
The key aspect is the loss of information and not the omission of
reading the manual.

With regards,
Kain
___
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] Fix for stash-next pointer (fix for the fix)

[Ross Berteig]

On 8/17/2016 1:01 PM, Warren Young wrote:

 It would indeed be nice if Fossil told you up front, as you said.

The documentation for --force doesn’t explain this second usage,
either. It only talks about “uncommitted changes,” which is not quite
the same thing as stashed changes, at least to my mind.
“Uncommitted” implies that committing them is the intent, whereas
stashed changes may never be committed; if I was certain about
keeping these changes or throwing them away, they wouldn’t be in the
stash, they’d be committed or reverted.

So, maybe you want to prepare a documentation patch rather than a functionality 
patch.


The current (tip of trunk) help text for fossil close reads:

$ fossil close --help
Usage: fossil close ?OPTIONS?

The opposite of "open".  Close the current database connection.
Require a -f or --force flag if there are unsaved changes in the
current check-out or if there is non-empty stash.

Options:
  --force|-f  necessary to close a check out with uncommitted
  changes

See also: open

The text "or if there is a non-empty stash" was added by check-in 
[c6aedbd0] on 2013-06-22.


I could see rewording the text for --force to be a little more succinct 
and not imply something that contradicts the paragraph above it. But all 
in all, this is pretty clear, IMHO.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
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] Fix for stash-next pointer (fix for the fix)

[Warren Young]

On Aug 17, 2016, at 12:33 PM, Kain Abel  wrote:
> 
> Hi Warren,
> 
> 2016-08-17 17:43 GMT+02:00 Warren Young :
>> On Aug 16, 2016, at 6:45 AM, Kain Abel  wrote:
>>> Oh, that surprises me now. This implicit behavior is not explicit
>>> documented. There is no warning that all stashed changes will be also
>>> dropped when repository will be closed. Neither in 'stash --help' nor
>>> in 'close --help’.
>> 
>>$ f close
>>closing the checkout will delete your stash
> 
> Uh, reading is also not my forte and I wasted your time. :(

I wouldn’t say that.  It would indeed be nice if Fossil told you up front, as 
you said.  I was just pointing out that it warns you before deleting the stash, 
and requires that you give --force to close it anyway, or that you manually 
empty the stash first.

The documentation for --force doesn’t explain this second usage, either.  It 
only talks about “uncommitted changes,” which is not quite the same thing as 
stashed changes, at least to my mind.  “Uncommitted” implies that committing 
them is the intent, whereas stashed changes may never be committed; if I was 
certain about keeping these changes or throwing them away, they wouldn’t be in 
the stash, they’d be committed or reverted.

So, maybe you want to prepare a documentation patch rather than a functionality 
patch.
___
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] Fix for stash-next pointer (fix for the fix)

[Kain Abel]

Hi Warren,

2016-08-17 17:43 GMT+02:00 Warren Young :
> On Aug 16, 2016, at 6:45 AM, Kain Abel  wrote:
>> Oh, that surprises me now. This implicit behavior is not explicit
>> documented. There is no warning that all stashed changes will be also
>> dropped when repository will be closed. Neither in 'stash --help' nor
>> in 'close --help’.
>
> $ f close
> closing the checkout will delete your stash

Uh, reading is also not my forte and I wasted your time. :(
___
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] Fix for stash-next pointer (fix for the fix)

[Warren Young]

On Aug 16, 2016, at 6:45 AM, Kain Abel  wrote:
> 
> 2016-08-15 17:58 GMT+02:00 Warren Young :
>> 
>> [...] All stashes go away when you close the repo.
> 
> Oh, that surprises me now. This implicit behavior is not explicit
> documented. There is no warning that all stashed changes will be also
> dropped when repository will be closed. Neither in 'stash --help' nor
> in 'close --help’.

$ f close
closing the checkout will delete your stash

___
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] Fix for stash-next pointer (fix for the fix)

[Kain Abel]

Hi Warren,

2016-08-15 17:58 GMT+02:00 Warren Young :
>
> [...] All stashes go away when you close the repo.

Oh, that surprises me now. This implicit behavior is not explicit
documented. There is no warning that all stashed changes will be also
dropped when repository will be closed. Neither in 'stash --help' nor
in 'close --help'.

It was clear that stash is supposed for a temporary storage. But not,
that it does not will survive the closing operation.

This explains at least the amazement above.

Thanks for the remarks on this technical detail,
Kain
___
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] Fix for stash-next pointer (fix for the fix)

[Warren Young]

On Aug 15, 2016, at 9:58 AM, Warren Young  wrote:
> 
> if your only complaint is that typing long integers is tedious, simply 
> closing and re-opening the repository in the same directory will reset the 
> stash counter.  All stashes go away when you close the repo.

Another thought: Unless you’re going to copy your .fslckout DB from one machine 
to the next, this means that even if you never close and reopen the repo on a 
given machine, you will at least reset the stash counter when you replace your 
current development machine.

Therefore, I would be surprised if any Fossil users have even 5-digit stash 
IDs.  One way or another, the stash counter is going to be reset occasionally.

___
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] Fix for stash-next pointer (fix for the fix)

[Warren Young]

On Aug 14, 2016, at 10:47 AM, Kain Abel  wrote:
> 
> 2016-08-13 19:45 GMT+02:00 Richard Hipp :
> 
>> But you still have not made your case for why growth of the stash id
>> is a bad thing.
> 
> I know, it would be purely cosmetic.
> 
> What is largest possible stash id on 32 bit systems?

I covered that in my other reply.

But as for cosmetics, if your only complaint is that typing long integers is 
tedious, simply closing and re-opening the repository in the same directory 
will reset the stash counter.  All stashes go away when you close the repo.
___
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] Fix for stash-next pointer (fix for the fix)

[Kain Abel]

HI,

2016-08-13 19:45 GMT+02:00 Richard Hipp :

> But you still have not made your case for why growth of the stash id
> is a bad thing.

I know, it would be purely cosmetic.

What is largest possible stash id on 32 bit systems?

My stash ID's after testing are now

$ fos pool
6: [7ad8230273fa79] on 2016-02-15 23:04:46
  (comments removed)
8: [7ad8230273fa79] on 2016-02-15 23:17:34
   10: [7ad8230273fa79] on 2016-02-16 03:32:31
   11: [8ed01e8021d415] on 2016-02-26 04:09:25
   12: [b06cd631f18043] on 2016-03-07 23:06:20
   13: [57f1eaecb80dcf] on 2016-03-27 23:28:45

and next would being 23 (in the pristine version).

Maybe I use this function even incorrect and should discard the slots faster.
They contains/keeps small changes here and there...

Whatever:
It's not my intention to belittle your work. I try my best from a
luser's perspective.

Thanks for your time and work,
Kain
___
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] Fix for stash-next pointer (fix for the fix)

[Richard Hipp]

On 8/13/16, Kain Abel  wrote:
> The next try: another version.
>
> (Prevents the growth from stash id after many push and pop operations.)

But you still have not made your case for why growth of the stash id
is a bad thing.

>
> Just for the sake of completeness,
> Kain
>


-- 
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] Fix for stash-next pointer (fix for the fix)

[Kain Abel]

The next try: another version.

(Prevents the growth from stash id after many push and pop operations.)

Just for the sake of completeness,
Kain


stash-next_fix_fix.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