subject:"\[fossil\-users\] Right way to try something new and save\/revert\?"

On Wed, 09 Jan 2013 12:10:35 +0100, Gilles
gilles.gana...@free.fr wrote:
Am I correct in understanding that this is the right way to proceed to
try some new code, and either save it (whether it works or not, just
as a track-record) or discard it?

I have another question: fossil branch ls lists branches available
in the repo, but is there a command to list all the files/revisions
that have been commited to the experimental branch?

Thank you.

___
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] Right way to try something new and save/revert?

On Fri, Jan 25, 2013 at 11:59 AM, Gilles gilles.gana...@free.fr wrote:

 I have another question: fossil branch ls lists branches available
 in the repo, but is there a command to list all the files/revisions
 that have been commited to the experimental branch?


There are two ways i know of to do that, but both show the files _in_ the
branch, whether or not they have been modified _in that branch_ since the
branch was created:

1) The web interface (/dir) allows one to browse a specific branch.

http://fossil-scm.org/index.html/dir?ci=encoding-glob

2) The JSON dir command with the checkin option:

[stephan@host:~/cvs/fossil/fossil]$ f json dir -checkin encoding-glob
{
fossil:bb63588e1bd65f1556bcf778a49833eda55c4e14,
timestamp:1359113099,
command:dir,
procTimeMs:36,
payload:{
name:/,
checkin:f480173856136f6ad30686edc875de969a6f1a91,
entries:[
...
{
name:COPYRIGHT-BSD2.txt,
uuid:c7dd1de9f9539a5a859c2b41fe4560604a774476,
size:1528,
timestamp:1274036925,
downloadPath:/raw/COPYRIGHT-BSD2.txt?name=c7dd1de9f9539a5a859c2b41fe4560604a774476
},

...
}

but note that the output format from /json/dir is a bit dumb (IMO). i would
be very glad to get input about how to improve it.

-- 
- 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] Right way to try something new and save/revert?

On Fri, 25 Jan 2013 12:28:25 +0100, Stephan Beal
sgb...@googlemail.com wrote:
There are two ways i know of to do that, but both show the files _in_ the
branch, whether or not they have been modified _in that branch_ since the
branch was created:

Thanks for the info.

I don't understand what you mean by both show the files _in_ the
branch, whether or not they have been modified _in that branch_ since
the branch was created. Do you meant that they'll list all files in a
branch, even those that were only commited once since the branch was
created?

I prefer to use the CLI because it's faster than the web interface.
Hopefully there's an easier way than running json dir and reading
its output.

What about using tags to list files, eg. trunk vs. experimental?

___
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] Right way to try something new and save/revert?

On Fri, Jan 25, 2013 at 12:41 PM, Gilles gilles.gana...@free.fr wrote:

 I don't understand what you mean by both show the files _in_ the
 branch, whether or not they have been modified _in that branch_ since
 the branch was created. Do you meant that they'll list all files in a
 branch, even those that were only commited once since the branch was
 created?


By that i meant: your question was a way to see what has been committed
to that branch. The /dir and /json/dir commands show what is in the
branch, regardless of whether it was committed in that branch or imported
via the parent branch when the branch was created.


 I prefer to use the CLI because it's faster than the web interface.
 Hopefully there's an easier way than running json dir and reading
 its output.


fossil co branchname
ls -la

There is no equivalent of the /dir page for the CLI.


 What about using tags to list files, eg. trunk vs. experimental?


That works with the /dir page and /json/dir command.

-- 
- 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] Right way to try something new and save/revert?

On Fri, Jan 25, 2013 at 1:14 PM, Stephan Beal sgb...@googlemail.com wrote:

 There is no equivalent of the /dir page for the CLI.


It appears that i lied, at least partially: Martin shows us the 'ls'
command (which is new to me!).

-- 
- 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] Right way to try something new and save/revert?

On Fri, Jan 25, 2013 at 1:11 PM, Martin Gagnon eme...@gmail.com wrote:

 Is this a bug or I mis understand meaning of ?VERSION? for the ls command ?


FWIW: it appears to me that it does not react intuitively when given a
branch name as a version:

[stephan@host:~/cvs/fossil/fossil]$ fossil ls encoding-glob --age | sort -r
| head
2013-01-25 08:53:54  win/Makefile.msc
2013-01-25 08:53:54  src/makemake.tcl
2013-01-24 15:19:08  win/Makefile.mingw
2013-01-24 15:19:08  src/main.mk
2013-01-24 14:38:19  src/stat.c

those changes were all made in the trunk branch, not the encoding-glob
branch, and have not been merged into that branch since then.

-- 
- 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] Right way to try something new and save/revert?

On Fri, 25 Jan 2013 13:16:46 +0100, Stephan Beal
sgb...@googlemail.com wrote:
It appears that i lied, at least partially: Martin shows us the 'ls'
command (which is new to me!).

Thanks guys.

The json command doesn't exist in the Fossil I have (1.24
[0c65916136]):

===
[C:\]fossil json dir -checkin experimental
fossil: fossil: unknown command: json
fossil: use help for more information
===

It seems a bit involved just to know what revisions are available in a
given branch.

What about switching to another branch (eg. going from trunk to
experimental), and simply running fossil ls? Will that list the
revisions without touching the files in my work directory?

___
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] Right way to try something new and save/revert?

On Fri, 25 Jan 2013 14:14:20 +0100, Gilles
gilles.gana...@free.fr wrote:
What about switching to another branch (eg. going from trunk to
experimental), and simply running fossil ls? Will that list the
revisions without touching the files in my work directory?

I notice that fossil update experimental -n doesn't say which work
files will be replaced by what's in the experimental branch in the
repo (1 file modified.):

===
UPDATE dummy.c
---
updated-to:   80ebe786997e4fc943bbc2d9564f8bb727e81675 2013-01-11
16:36:56 UTC
tags: experimental
comment:  Testing branches (user: Fred)
changes:  1 file modified.
===

Generally speaking, I find running update followed by commands to
list which files/revisions are available and their contents (ls,
timeline, finfo, etc.) a bit dangerous. It'd be coold if there were a
simple way to list files/revisions in a branch without actually
checking out anything into the work directory.

___
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] Right way to try something new and save/revert?

On Fri, 25 Jan 2013 14:38:25 +0100, Gilles
gilles.gana...@free.fr wrote:
I notice that fossil update experimental -n doesn't say which work
files will be replaced by what's in the experimental branch in the
repo (1 file modified.):

===
UPDATE dummy.c
---
updated-to:   80ebe786997e4fc943bbc2d9564f8bb727e81675 2013-01-11
16:36:56 UTC
tags: experimental
comment:  Testing branches (user: Fred)
changes:  1 file modified.
===

My mistake: I was looking lower and didn't see the UPDATE line. Not
big enough :-D

___
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] Right way to try something new and save/revert?

2013-01-25 Thread Themba Fletcher

On Fri, Jan 25, 2013 at 2:59 AM, Gilles gilles.gana...@free.fr wrote:
 On Wed, 09 Jan 2013 12:10:35 +0100, Gilles
 gilles.gana...@free.fr wrote:
Am I correct in understanding that this is the right way to proceed to
try some new code, and either save it (whether it works or not, just
as a track-record) or discard it?

 I have another question: fossil branch ls lists branches available
 in the repo, but is there a command to list all the files/revisions
 that have been commited to the experimental branch?


I think 'fossil diff --brief --branch experimental' might be what
you're looking for.



 Thank you.

 ___
 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] Right way to try something new and save/revert?

2013-01-15 Thread Gilles

On Fri, 11 Jan 2013 20:55:23 +0400, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
The logic behind `fossil update` is like follows.

Thanks for the infos + suggestion in the other post.

___
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] Right way to try something new and save/revert?

2013-01-11 Thread Konstantin Khomoutov

On Fri, 11 Jan 2013 13:06:17 +0100
Gilles gilles.gana...@free.fr wrote:

 Am I correct in understanding that this is the right way to proceed
 to try some new code, and either save it (whether it works or not,
 just as a track-record) or discard it?

 So the right way to experiment and keep tried code for later reference
 is to save those trials in a branch, distinct from the trunk.

 But since I've never used branching, I'm not clear about how to see
 which files have been saved in the branch vs. those in the trunk,

You don't need this: a branch diverges from the trunk (in your case),
rather than appearing out of the void, so initially it has the same
files in the same state the trunk does.  Moreover, the Fossil's
philosophy is that a new branch is only created when the first commit
on it is made, so you start with the trunk, do some changes then do

fossil commit --branch crazy_idea

and only then your new branch comes into existence.

Getting the diff between the starting point of the branch (or an
earlier state) is quite rarely needed -- most of the time you're
interested in the diff between your work directory (local changes) and
its base version (the last recorded commit on the current branch).
If you still need the diff between two arbitrary commits, use

fossil diff --from A --to B

where A and B are either branch/tag names or (possibly abbreviated)
hashes of the relevan commits, extracted from the timeline view.

You can omit either --from or --to, so, to diff your current checkout
to the trunk, just use

fossil diff --from trunk

 and how to check the changes made in a branch to such and such file,

Fire up Fossil web UI and click on the links marked patch and diff
in the commit view.

 and how to go back and forth between the trunk and the branch before
 applying commit.

Technically, just by doing `fossil update branchname` as this tries
to merge your uncommitted local changes with the branchname you're
switching your open checkout to.

But, again, what you're asking for is not needed as this is not how
VCSes work, so don't do that.  Instead, implement your feature on your
branch, and if you're OK with it and want it in your mainline (the
trunk), go back to the trunk and then *merge* your feature branch into
it -- this will bring all the changes implemented on that feature
branch and will record that your new commit has two parents (the trunk
and the feature branch) so you have understanable history record.
___
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] Right way to try something new and save/revert?

2013-01-11 Thread Gilles

On Fri, 11 Jan 2013 17:19:40 +0400, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
 and how to check the changes made in a branch to such and such file,

Fire up Fossil web UI and click on the links marked patch and diff
in the commit view.

This is really what I want to do: Being able to see all the things I
tried on a file in the branch. Most of the time, I want to keep track
of things I tried just in case instead of just forgetting about them
with fossil revert.

Can this be done with calling a Windows application, either a regular
editor or a differ instead of the Fossil web server? I prefer working
with dedicated applications.

Technically, just by doing `fossil update branchname` as this tries
to merge your uncommitted local changes with the branchname you're
switching your open checkout to.

I was under the impression that update simply told Fossil than any
subsequent commit should be done on that thread/trunk. Good to know
that update will perform a merge, so it has consequences.

___
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] Right way to try something new and save/revert?

2013-01-11 Thread Gilles

On Fri, 11 Jan 2013 17:11:44 +0100, Gilles
gilles.gana...@free.fr wrote:
This is really what I want to do: Being able to see all the things I
tried on a file in the branch. Most of the time, I want to keep track
of things I tried just in case instead of just forgetting about them
with fossil revert.

What I'm driving at:
1. Keep tried but NOK algos in a branch called eg. experimental
2. Find a simple way to locate old algo's I know I tried before by
searching Fossil, regardless of which branch they are (trunk or
experimental).

I know Fossil doesn't support grep yet, but I find it useful to  being
able to just commit code and know for sure that I can find anything in
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] Right way to try something new and save/revert?

2013-01-11 Thread Konstantin Khomoutov

On Fri, 11 Jan 2013 17:11:44 +0100
Gilles gilles.gana...@free.fr wrote:

Fire up Fossil web UI and click on the links marked patch and
diff in the commit view.

This is really what I want to do: Being able to see all the things I
tried on a file in the branch. Most of the time, I want to keep track
of things I tried just in case instead of just forgetting about them
with fossil revert.

`fossil revert` is there for special whoops! cases, not for
organising some sort of serious workflow around it.

Can this be done with calling a Windows application, either a regular
editor or a differ instead of the Fossil web server? I prefer working
with dedicated applications.

There's no official GUI front-end for fossil, but there are several
attempts at creating such a thing. Google mail archives for it,
using something like

http://www.google.com/search?q=GUI+site%3Amail-archive.com%2Ffossil-users%40lists.fossil-scm.org

to get the relevant discussions/links. Using GUI diffing programs was
also discussed several times.

Technically, just by doing `fossil update branchname` as this tries
to merge your uncommitted local changes with the branchname you're
switching your open checkout to.

I was under the impression that update simply told Fossil than any
subsequent commit should be done on that thread/trunk. Good to know
that update will perform a merge, so it has consequences.

The logic behind `fossil update` is like follows.

Your work tree (working directory, current checkout and whatever else
it's being named) is always based on some state stored in the
repository (except for the special case when the repository has no
commits at all yet). So the main task of `fossil update` is to bring
your work tree to the state held by the commit you supplied to this
command (directly, or via the name of a branch or a tag). Of course,
when fossil does this, it has to be non-destructive: it should not
stomp over untracked files (files present in the work tree but not
being managed by fossil) and it should preserve your local
modifications, if any, which it does by merging.

After than, when you modify something and record a commit, that
new commit inherits certain properties from the base commit of your
work tree, and if that commit is on a branch, then your new commit
will be on that same branch, too.
___
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] Right way to try something new and save/revert?

2013-01-11 Thread Konstantin Khomoutov

On Fri, 11 Jan 2013 17:25:24 +0100
Gilles gilles.gana...@free.fr wrote:

[...]
 What I'm driving at:
 1. Keep tried but NOK algos in a branch called eg. experimental
 2. Find a simple way to locate old algo's I know I tried before by
 searching Fossil, regardless of which branch they are (trunk or
 experimental).
 
 I know Fossil doesn't support grep yet, but I find it useful to  being
 able to just commit code and know for sure that I can find anything in
 the repo.

You could go for documenting your experiments then.

First of all, you can assign arbitrary tags to the tip commits of your
experimental lines of history.  A tag view is there to select the one
you need.

Another easy possibilty is the wiki: you can refer to any commit using
its SHA-1 name in square brackets, so you can create a page titled,
say, experiments and roll something like this:

h2My experiments/h2

* [44c9e93a9187a07340da8b2984b2118990637d5a|A crazy idea]
* [8a428d5c2a0097418170509ab03faed0a335f796|Using bars to style foos]
...

where you get those SHA-1 commit names from the commit views.
The end result is that you have a nice-looking list of your
experimental lines of history, decorated by arbitrary comments.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Right way to try something new and save/revert?

Hello

Am I correct in understanding that this is the right way to proceed to
try some new code, and either save it (whether it works or not, just
as a track-record) or discard it?

To try some new code:
1. Commit current code
2. Try new code
3.
a. if OK, commit new code : fossil commit -m New stuff
b. if NOK and don't care to save it, just go back to previous code:
fossil revert myfile.c
c. if NOK but want to keep track of attempt, commit and go back to n-1
:
fossil commit -m Failed attempt
fossil finfo myfile.c : write down UUID (first hash) of n-1 revision
fossil revert -r UUID myfile.c

Thank you.

___
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] Right way to try something new and save/revert?

2013-01-09 Thread Eduardo Morras

On Wed, 09 Jan 2013 12:10:35 +0100
Gilles gilles.gana...@free.fr wrote:

 Hello
 
 Am I correct in understanding that this is the right way to proceed to
 try some new code, and either save it (whether it works or not, just
 as a track-record) or discard it?
 
 To try some new code:
 1. Commit current code
 2. Try new code
 3.
 a. if OK, commit new code : fossil commit -m New stuff
 b. if NOK and don't care to save it, just go back to previous code:
 fossil revert myfile.c
 c. if NOK but want to keep track of attempt, commit and go back to n-1
 :
 fossil commit -m Failed attempt
 fossil finfo myfile.c : write down UUID (first hash) of n-1 revision
 fossil revert -r UUID myfile.c

If in your step 2 you add/remove/move files you should fossil addremove 
before the commit.

Remember to open the repository before any change to your code, if not, when 
you do fossil open rep.fossil, it will note it's different from fossilized 
source tree and undo all your changes.

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


---   ---
Eduardo Morras emorr...@yahoo.es
___
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] Right way to try something new and save/revert?

On Wed, 9 Jan 2013 12:23:23 +0100, Eduardo Morras
emorr...@yahoo.es wrote:
 2. Try new code

If in your step 2 you add/remove/move files you should fossil addremove 
before the commit.

Thanks for the tip. I usually only make changes to existing files,
usually just localized changes in a single file, but it's indeed
important to keep in mind.

Remember to open the repository before any change to your code, if not, when 
you do fossil open rep.fossil, it will note it's different from fossilized 
source tree and undo all your changes.

I always leave Fossil open, so it's not an issue, but I'll keep that
in mind. Thank you.

___
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] Right way to try something new and save/revert?

2013-01-09 Thread Richard Hipp

On Wed, Jan 9, 2013 at 6:10 AM, Gilles gilles.gana...@free.fr wrote:

 Hello

 Am I correct in understanding that this is the right way to proceed to
 try some new code, and either save it (whether it works or not, just
 as a track-record) or discard it?

 To try some new code:
 1. Commit current code
 2. Try new code
 3.
 a. if OK, commit new code : fossil commit -m New stuff
 b. if NOK and don't care to save it, just go back to previous code:
 fossil revert myfile.c
 c. if NOK but want to keep track of attempt, commit and go back to n-1
 :
 fossil commit -m Failed attempt
 fossil finfo myfile.c : write down UUID (first hash) of n-1 revision
 fossil revert -r UUID myfile.c


I'd do it this way:

   fossil commit -m Failed Attempt --branch dead-end
   fossil up prev

That will save your failed attempt in your history forever.  The failed
attempt will be on a branch, however, out of the way.  I avoid putting
non-working code on the trunk, since that will cause problems for future
bisects.

If you don't what to save your failed attempt forever, but just want to
keep it around for a few days (or weeks) in case you later decide to go
back it it, I'd save it in the stash instead:

   fossil stash save

The previous command will save all your changes in a stash entry, then
revert your check-out to its pristine state.
-- 
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] Right way to try something new and save/revert?

2013-01-09 Thread Ramon Ribó

  Hello,

  Much nicer:

 fossil add kk.cc
 fossil commit -m v1
 (some failed changes)
 fossil commit -m failed attempt --branch failed_attempt
 fossil update trunk
 (some changes)
 fossil commit -m good


Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com  ram...@compassis.com
c/ Tuset, 8 7-2  tel. +34 93 218 19 89
08006 Barcelona, Spainfax. +34 93 396 97 46


2013/1/9 Gilles gilles.gana...@free.fr:
 Hello

 Am I correct in understanding that this is the right way to proceed to
 try some new code, and either save it (whether it works or not, just
 as a track-record) or discard it?

 To try some new code:
 1. Commit current code
 2. Try new code
 3.
 a. if OK, commit new code : fossil commit -m New stuff
 b. if NOK and don't care to save it, just go back to previous code:
 fossil revert myfile.c
 c. if NOK but want to keep track of attempt, commit and go back to n-1
 :
 fossil commit -m Failed attempt
 fossil finfo myfile.c : write down UUID (first hash) of n-1 revision
 fossil revert -r UUID myfile.c

 Thank you.

 ___
 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] Right way to try something new and save/revert?

2013-01-09 Thread Konstantin Khomoutov

On Wed, 09 Jan 2013 12:10:35 +0100
Gilles gilles.gana...@free.fr wrote:

 Am I correct in understanding that this is the right way to proceed to
 try some new code, and either save it (whether it works or not, just
 as a track-record) or discard it?
 
 To try some new code:
 1. Commit current code
 2. Try new code
 3.
 a. if OK, commit new code : fossil commit -m New stuff
 b. if NOK and don't care to save it, just go back to previous code:
 fossil revert myfile.c
 c. if NOK but want to keep track of attempt, commit and go back to n-1
 :
 fossil commit -m Failed attempt
 fossil finfo myfile.c : write down UUID (first hash) of n-1 revision
 fossil revert -r UUID myfile.c

AFAIK, the paradigm to handle messed up commits in Fossil is to move
them to a special branch, say, named mistake.  You do this from the
web interface.  So basically you can do a series of commits and then
decide that idea was a dead-end.  So you can go to the first commit of
that dead-end leaf and change its branch to, say, dead-end.
You then can `fossil up` to the commit preceding the first commit in
the dead-end leaf and start hacking away a new line of history.
___
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] Right way to try something new and save/revert?

On Wed, 9 Jan 2013 06:37:54 -0500, Richard Hipp
d...@sqlite.org wrote:
I'd do it this way:

   fossil commit -m Failed Attempt --branch dead-end
   fossil up prev

That will save your failed attempt in your history forever.  The failed
attempt will be on a branch, however, out of the way.  I avoid putting
non-working code on the trunk, since that will cause problems for future
bisects.

If you don't what to save your failed attempt forever, but just want to
keep it around for a few days (or weeks) in case you later decide to go
back it it, I'd save it in the stash instead:

   fossil stash save

The previous command will save all your changes in a stash entry, then
revert your check-out to its pristine state.

Thanks much for the feedback. I guess the time has come to start using
branching :-)

I didn't know about stash but I'd rather keep all attemps with no
limit, so I guess I'll use branching instead.

Ramon below mentions fossil update trunk instead of fossil update
prev: Does it make a difference?

___
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] Right way to try something new and save/revert?

2013-01-09 Thread Richard Hipp

On Wed, Jan 9, 2013 at 7:13 AM, Gilles gilles.gana...@free.fr wrote:


 Ramon below mentions fossil update trunk instead of fossil update
 prev: Does it make a difference?


Not in this case, since the previous check-in will be on trunk - they will
be the same thing.



 --

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] Right way to try something new and save/revert?