Re: [fossil-users] feature implemented or suggestion for stash

[Ross Berteig]

On 4/14/2016 11:10 AM, Stephan Beal wrote:

On Thu, Apr 14, 2016 at 7:00 PM, Warren Young > wrote:
On Apr 12, 2016, at 11:30 PM, Stephan Beal > wrote:
> i haven't ever bisected.
Wow…

I don’t bisect every day, but when I do bisect, I bisect with Fossil. :)


The ability to bisect is one of the strongest arguments in favor of
version control.


I've needed it in the past, but as luck had it only on projects from 
before I knew about fossil, and I suspect before fossil really existed. 
CVS was fine for keeping a change log and record of the past from which 
with great luck and careful usage one *might* be able to return to a 
past build. Bisect was not something that would have been easily done 
with it.


Since I've been using fossil, luck has mostly kept me from needing to 
search for obscure bugs that were latent until noticed. But from 
watching the list and noticing the ease with which others have used it 
for that purpose, it was clearly not only a compelling argument in favor 
of version control, but also a compelling reason to never check in 
anything to trunk that breaks the build.



i admit that it's a fantastic capability, i've just never needed to use
it. (Contrast with "fossil clean" - i have Opinions about anyone other
than myself cleaning up my source trees, and simply _won't_ use that
feature.)


I'm 100% with Stephan on this one. On those rare occasions where I've 
wanted the effect of fossil clean, I've opened a fresh working directory 
instead.


>


--
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] feature implemented or suggestion for stash

[Stephan Beal]

On Thu, Apr 14, 2016 at 7:00 PM, Warren Young  wrote:

> On Apr 12, 2016, at 11:30 PM, Stephan Beal  wrote:
> >
> > i haven't ever bisected.
>
> Wow…
>
> I don’t bisect every day, but when I do bisect, I bisect with Fossil. :)
>

i've just been lucky - never needed to use it to find where a particular
problem arrived :). (But that's admittedly luck, rather than any form of
skill!)


> Bisecting is most useful when you get a bug report from the field and
> can’t see from that report how any of the recent changes caused the
> failure.


See, if anyone other that myself used my software, i might have needed it
;).



> I used bisect on Fossil itself to find the regression that broke sorting
> in the Tickets view, fixed in [0e555dee6].  The problem was introduced
> about 6 months prior to the bug’s discovery.  How would you have found a
> problem like that without bisecting?
>

i'd have left it to you to find :-D!


> I suppose if you’re working on software with 100% regression test coverage,


LOL! Nope - just lucky. i was born in Las Vegas - maybe that has something
to do with it ;).


> The ability to bisect is one of the strongest arguments in favor of
> version control.
>

i admit that it's a fantastic capability, i've just never needed to use it.
(Contrast with "fossil clean" - i have Opinions about anyone other than
myself cleaning up my source trees, and simply _won't_ use that 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] feature implemented or suggestion for stash

[Richard Hipp]

On 4/14/16, Warren Young  wrote:
>
> I suppose if you’re working on software with 100% regression test coverage,
> such problems would never become buried in the project history: as soon as a
> change breaks things, you get told about it by the test harness.

Not so.  The better the test suite, the more you need bisect.  With a
really strong test suite what happens is that the occasional bug that
does slip in is probably something extremely subtle and it can go a
very long time (years) without being noticed.  Finding the origin of
the problem becomes very difficult without bisect.

Note that bisect can also be used to figure out when a problem was
fixed!  This happened on SQLite just moments ago.  (See
http://www.mail-archive.com/sqlite-users%40mailinglists.sqlite.org/msg07964.html
for the mailing list post).  The OP was concerned about SQLite not
making a wise index choice.  He sent in the database, and I noticed
that my current version of SQLite was making the right choice.  I used
bisect to figure out exactly which check-in fixed the problem, which
also revealed exactly what the problem was without me having to spend
time debugging it.

>
> The ability to bisect is one of the strongest arguments in favor of version
> control.

+1

-- 
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] feature implemented or suggestion for stash

[Warren Young]

On Apr 12, 2016, at 11:30 PM, Stephan Beal  wrote:
> 
> i haven't ever bisected.

Wow…

I don’t bisect every day, but when I do bisect, I bisect with Fossil. :)

Bisecting is most useful when you get a bug report from the field and can’t see 
from that report how any of the recent changes caused the failure.  So, you 
start with the last-known-good version, and quickly bisect your way toward the 
checkin that broke things.

I used bisect on Fossil itself to find the regression that broke sorting in the 
Tickets view, fixed in [0e555dee6].  The problem was introduced about 6 months 
prior to the bug’s discovery.  How would you have found a problem like that 
without bisecting?

I suppose if you’re working on software with 100% regression test coverage, 
such problems would never become buried in the project history: as soon as a 
change breaks things, you get told about it by the test harness.  But even 
Fossil, which is about as well-tested as software gets, in my experience, had 
this one slip by because there is no regression testing done on the UI code.

The ability to bisect is one of the strongest arguments in favor of version 
control.
___
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 implemented or suggestion for stash

[Stephan Beal]

On Tue, Apr 12, 2016 at 8:01 PM, fran  wrote:

> Bug fixing sometimes involves unplanned commits with nonsense because
> of the hurry.
> The flow is fast and crude changesets (the stash, right?).


i disagree: branches are for that purpose. The stash is not.


> Much of these commits
> just aren't useful to the course of the project at all.
>

That's where private branches are useful (but i personally have no
experience with them).


> I view the stash as a quick and dirty notepad (we all agree on this)
>

No, we don't ;). It's a place to store something very briefly while you
work on something else which has taken priority. As Andy pointed out,
though, simply opening a repo multiple times in different directories can
also be used for that.

which is sometimes what
> you need when bisecting: Begin the bisection, add some traces here and
> there,
> stash the changeset, checking if the error is found, going to the next
> bisected version and put some traces there too, and on...
>

It might be useful in that context - i haven't ever bisected.


> you need to confirm your conclusions. What you have? You have the
> 'bisect chart' and you have several stashes lying on top of the
> bisected versions. So you use the 'stash goto' command (hey, it is
> there for something, right?) and refine the tests and traces.
>

That might be what goto is for - i haven't used it, so can't say :/.

I presented the topic as a 'new feature' but it is not new at all. It
> is what the stash
> can do in its current form. I just suggest that showing the relevant
> information more easily makes fossil more flexible and clear in the end.
>

That sounds reasonable enough to me (even though i think you're abusing the
stash ;). i can't personally commit to making this change (my ability to
type is still relatively limited due to elbow nerve damage caused by too
much typing(!), and recent projects at work have caused it to get worse),
but maybe someone listening in will pick it up.

-- 
- 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] feature implemented or suggestion for stash

[fran]

I tried to be the more accurate I can given I am not
english spoken to expose what I wanted to say in the first place. Excuse me
for the extension of this but I think there is an interesting point
here and a patch
---

Bug fixing sometimes involves unplanned commits with nonsense because
of the hurry.
The flow is fast and crude changesets (the stash, right?). Much of these commits
just aren't useful to the course of the project at all.

I view the stash as a quick and dirty notepad (we all agree on this)
which is sometimes what
you need when bisecting: Begin the bisection, add some traces here and there,
stash the changeset, checking if the error is found, going to the next
bisected version and put some traces there too, and on...

At some point you're supposed to find the problem. If the bug was ugly
(as every bug)
you need to confirm your conclusions. What you have? You have the
'bisect chart' and you have several stashes lying on top of the
bisected versions. So you use the 'stash goto' command (hey, it is
there for something, right?) and refine the tests and traces.

Thats what I meant by saying I have several stashes over several versions
lying in the working copy. Not to share the stashes. Not to store the stash for
long periods. Not to make the stash a sophisticated big feature. Not to modify
its current behaviour.

This flow works naturally only if the 'stash list' cooperates giving a
bigger overview
of the stashes: the baseline of every stash should be presented
in a more human manner (not just the uuid, but a summary of the version so you
can get immediate grasp of the involved versions you modified during
the bisection.

Everyone has his own flow on this but I guess we all agree that the
process should be aided by fossil.
I'm pretty sure if you used commits instead of the stash you will have to
meticulously purge those commits after concluding the task and here you face
the risk of obliterating data if you make a mistake (I know the purge
also need confirmation for this to happen). Or leave them in the
graph, won't hurt but you lost
the scope of the activity in the first place, the bisection, ending up
with commits you have get info by hand one by one. Using --private
commits here is the same...
What about opening the checkouts on other directories? This way you lose
precious bits of info fossil is handling single handed already (the
bisect and the stash).

I presented the topic as a 'new feature' but it is not new at all. It
is what the stash
can do in its current form. I just suggest that showing the relevant
information more easily makes fossil more flexible and clear in the end.

This patch gives a cosmetic enhancement to the 'stash list' command
making the workflow I'm talking about more obvious to the user:

Against trunk
uuid: 96dec24eaf2e7a604aee71faf2deb2421db4e035 2016-04-09 16:57:16 UTC

Index: src/stash.c
==
--- src/stash.c
+++ src/stash.c
@@ -422,15 +422,17 @@
 ** are listed, then only stash and revert the named files.  The
 ** "save" verb can be omitted if and only if there are no other
 ** arguments.  The "snapshot" verb works the same as "save" but
 ** omits the revert, keeping the check-out unchanged.
 **
-**  fossil stash list ?-v|--verbose?
-**  fossil stash ls ?-v|--verbose?
+**  fossil stash list ?-v|--verbose? ?-b|--baseline?
+**  fossil stash ls ?-v|--verbose? ?-b|--baseline?
 **
 ** List all changes sets currently stashed.  Show information about
-** individual files in each changeset if -v or --verbose is used.
+** about individual files in each changeset if -v or --verbose
+** is used. Show baseline checkout summary for each changeset
+** with -b or --baseline.
 **
 **  fossil stash show|cat ?STASHID? ?DIFF-FLAGS?
 **
 ** Show the content of a stash
 **
@@ -463,11 +465,11 @@
 **
 ** SUMMARY:
 **  fossil stash
 **  fossil stash save ?-m|--comment COMMENT? ?FILES...?
 **  fossil stash snapshot ?-m|--comment COMMENT? ?FILES...?
-**  fossil stash list|ls  ?-v|--verbose? ?-W|--width ?
+**  fossil stash list|ls  ?-v|--verbose? ?-b|--baseline? ?-W|--width ?
 **  fossil stash show|cat ?STASHID? ?DIFF-OPTIONS?
 **  fossil stash pop
 **  fossil stash apply ?STASHID?
 **  fossil stash goto ?STASHID?
 **  fossil stash rm|drop ?STASHID? ?-a|--all?
@@ -515,13 +517,15 @@
   }else
   if( memcmp(zCmd, "snapshot", nCmd)==0 ){
 stash_create();
   }else
   if( memcmp(zCmd, "list", nCmd)==0 || memcmp(zCmd, "ls", nCmd)==0 ){
-Stmt q, q2;
+Stmt q, q2, qbaseline;
+Blob sqlbaseline;
 int n = 0, width;
 int verboseFlag = find_option("verbose","v",0)!=0;
+int baselineFlag = find_option("baseline","b",0)!=0;
 const char *zWidth = find_option("width","W",1);

 if( zWidth ){
   width = atoi(zWidth);
   if( (width!=0) && (width<=46) ){
@@ -534,46 +538,97 @@
   verboseFlag = 

Re: [fossil-users] feature implemented or suggestion for stash

[Andy Bradford]

Thus said Stephan Beal on Mon, 11 Apr 2016 17:20:22 +0200:

> If i understand  correctly, that's what fossil intends  branches to be
> used for.  stashes are generally  not intended for  long-term storage.
> They're intended primarily  for "oops, i need to  quickly do something
> over  in this  other branch,  but  don't want  to check  this in  yet"
> situations.

I wonder if in this case it wouldn't be simpler just to:

mkdir /src/otherbranch &&
cd /src/otherbranch &&
fossil open /repo/project.fossil otherbranch

Andy
--
TAI64 timestamp: 4000570c4ce0
___
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 implemented or suggestion for stash

[fran]

all my samples include messages.

If that's the point then I could add all the 'interface' I need into the -m
flag
including console codes to draw boxes and stuff.



2016-04-11 13:15 GMT-03:00 Stephan Beal :

> On Mon, Apr 11, 2016 at 5:56 PM, fran  wrote:
>
>> The current listing displays
>> 1: [199b53d1d70361] on 2016-03-25 05:08:21
>>
>> To the new user this says "something 199b53d1d70361 got 'commited' on
>> such date"...
>>
>
> Have you tried using the -m option?
>
> [stephan@host:~]$ alias fsnap
> alias fsnap='fossil stash snapshot -m "snapshot @ $(date)" && echo
> "snapshot created"'
>
> you can provide any message you want to any given snapshot.
>
> --
> - 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
>
>
___
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 implemented or suggestion for stash

[fran]

forget the command line cases. The checkout was a children of the
checkout I was requesting to purge.

2016-04-11 13:45 GMT-03:00 fran :

> Whats the effect if I use the --integrate option?
>
> 2016-04-11 13:17 GMT-03:00 Tony Papadimitriou :
>
>> Once you’re ready to move the changes to a normal branch you simply merge
>> (but without the –integrate option or else the purge won’t work correctly),
>> and then purge the private branch.
>>
>>
> Didn't know about the purge, thats almost the same as 'hg strip', right?
>
> Given a working copy with just trunk, all I got was
> (( $13:29:36,1 )) fos purge f470e0bfb0
> cannot purge the current checkout
> (( $13:29:45,1 )) fos purge 23e3871e42
> cannot purge the current checkout
> (( $13:29:50,1 )) fos purge e7295d31d9
> cannot purge the current checkout
>
> what i'm doing wrong?
>
>
___
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 implemented or suggestion for stash

[fran]

Whats the effect if I use the --integrate option?

2016-04-11 13:17 GMT-03:00 Tony Papadimitriou :

> Once you’re ready to move the changes to a normal branch you simply merge
> (but without the –integrate option or else the purge won’t work correctly),
> and then purge the private branch.
>
>
Didn't know about the purge, thats almost the same as 'hg strip', right?

Given a working copy with just trunk, all I got was
(( $13:29:36,1 )) fos purge f470e0bfb0
cannot purge the current checkout
(( $13:29:45,1 )) fos purge 23e3871e42
cannot purge the current checkout
(( $13:29:50,1 )) fos purge e7295d31d9
cannot purge the current checkout

what i'm doing wrong?
___
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 implemented or suggestion for stash

[Tony Papadimitriou]

I don’t know if this will be of any help, but I moved away from using stash 
altogether for pretty much the same reasons you mention, plus one very 
important one for me that I don’t like about the stash: the content of the 
stash only stays on the current PC while I wanted it to follow the repo file 
(e.g., backup).

I have found the use of private branches to work much better than stash, and no 
need for remembering extra stash specific commands.  For one thing they behave 
just like normal branches (except of course for the syncing – which you 
wouldn’t want and you can’t do with the stash anyway).  Once you’re ready to 
move the changes to a normal branch you simply merge (but without the 
–integrate option or else the purge won’t work correctly), and then purge the 
private branch.  You commit and all your intermediate private branch commits 
appear as a single folded commit.  Finally, once every so often you also 
obliterate any purges, and rebuild with the –compress-only option to get the 
repo size repo back down.
I still haven’t figured out if there is any functionality one can achieve with 
a stash that cannot be achieved (and possibly better/easier) with the above 
procedure.
From: fran 

In my case I use the stash to mark checkpoints like  in a editor and 
after several checkpoints and getting sure the thing is working fine I begin to 
flush the stash.

I'm satisfied with the size and intent of the stash feature but the 'list'  
seems pretty raw to me. The 'timeline' too but at least the timeline part is 
pretty good covered with the ui.
___
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 implemented or suggestion for stash

[Stephan Beal]

On Mon, Apr 11, 2016 at 5:56 PM, fran  wrote:

> The current listing displays
> 1: [199b53d1d70361] on 2016-03-25 05:08:21
>
> To the new user this says "something 199b53d1d70361 got 'commited' on such
> date"...
>

Have you tried using the -m option?

[stephan@host:~]$ alias fsnap
alias fsnap='fossil stash snapshot -m "snapshot @ $(date)" && echo
"snapshot created"'

you can provide any message you want to any given snapshot.

-- 
- 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] feature implemented or suggestion for stash

[Stephan Beal]

On Mon, Apr 11, 2016 at 4:28 PM, fran  wrote:

> I never realized the presented uuid was actually the baseline.
> Stephan Beal said he wasn't even aware of the 'stash goto'
> command! And I (noob user) couldn't understand what
> the 'goto' would do.
>

There are _lots_ of features i don't know about (or don't use/need) in
fossil ;). i've never personally used bisect and wouldn't run 'clean' to
save my life (because i don't trust 'clean' rules i didn't write myself).
i.e., don't understand my (un)awareness of a given feature as a significant
indicator! ;)


> Considering this I implemented the feature:
>
> fossil stash ls ?-v|--verbose? ?-b|--baseline?
> ...
>


> I needed this feature because I'm used to keep several changesets
> lying around.
>

If i understand correctly, that's what fossil intends branches to be used
for. stashes are generally not intended for long-term storage. They're
intended primarily for "oops, i need to quickly do something over in this
other branch, but don't want to check this in yet" situations.

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

[fossil-users] feature implemented or suggestion for stash

[fran]

the stash could give more info about
the baseline checkout. It currently shows
just the checkout uuid.

I never realized the presented uuid was actually the baseline.
Stephan Beal said he wasn't even aware of the 'stash goto'
command! And I (noob user) couldn't understand what
the 'goto' would do.

Considering this I implemented the feature:

fossil stash ls ?-v|--verbose? ?-b|--baseline?

List all changes sets currently stashed.  Show information about
about individual files in each changeset if -v or --verbose
is used. Show baseline checkout summary for each changeset
with -b or --baseline.


Example of 'stash ls -b'

(( $11:13:42,v )) fos stash ls -b
1: over [199b53d1d70361] on 2016-03-25 05:08:21
   invierte logica de isaccepted
  BASELINE agrega flags -df -Df -Sf (user: suse tags: trunk)
2: over [dc52e154ee5f71] on 2016-03-25 12:53:13
   test another -l implementacion
  BASELINE eliminar fichero '.sum' solo si la descarga va a
proceder (user: suse tags: trunk)
3: over [789f55e34faeeb] on 2016-03-25 13:22:48
   directorio DATA
  BASELINE tiempo de espera al fallar descarga de 10 a 8
(user: suse tags: trunk)
4: over [789f55e34faeeb] on 2016-03-25 23:54:15
   endswith
  BASELINE tiempo de espera al fallar descarga de 10 a 8
(user: suse tags: trunk)
8: over [f470e0bfb042c2] on 2016-04-09 00:48:57
   calculos con let
  BASELINE *CURRENT* loggear momento en sincronizar
completamente el repo (user: suse tags: trunk)


Example of 'stash ls -v -b'

(( $11:13:44,v )) fos stash ls -b -v
1: over [199b53d1d70361] on 2016-03-25 05:08:21
   invierte logica de isaccepted
  BASELINE agrega flags -df -Df -Sf (user: suse tags: trunk)
  EDIT sync_void.ksh
2: over [dc52e154ee5f71] on 2016-03-25 12:53:13
   test another -l implementacion
  BASELINE eliminar fichero '.sum' solo si la descarga va a
proceder (user: suse tags: trunk)
  EDIT sync_void
3: over [789f55e34faeeb] on 2016-03-25 13:22:48
   directorio DATA
  BASELINE tiempo de espera al fallar descarga de 10 a 8
(user: suse tags: trunk)
  EDIT sync_void
4: over [789f55e34faeeb] on 2016-03-25 23:54:15
   endswith
  BASELINE tiempo de espera al fallar descarga de 10 a 8
(user: suse tags: trunk)
  EDIT sync_void
8: over [f470e0bfb042c2] on 2016-04-09 00:48:57
   calculos con let
  BASELINE *CURRENT* loggear momento en sincronizar
completamente el repo (user: suse tags: trunk)
  EDIT sync_void


I needed this feature because I'm used to keep several changesets
lying around. I implemented it using bits of the timeline formatting
and I dont' know if this change is considered useful for the completeness
of fossil.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users