Hi Andy,
On 10/21/2016 12:53 PM, Andy Bradford wrote:
Thus said Nikita Borodikhin on Fri, 21 Oct 2016 16:02:33 -0000:
== change sets - preparing the change ==
I often end up having several sets of unrelated changes. For example,
one set is my temporary change to the build system to disable some
things to make build process faster, but these changes are not
intended to come into the end product and are not to be committed.
You could simply open a new checkout and keep unrelated changes in
different checkouts of your repository. For example,
fossil new /tmp/test.fossil
mkdir /tmp/tinker && cd /tmp/tinker && fossil open /tmp/test.fossil
mkdir /tmp/explore && cd /tmp/explore && fossil open /tmp/test.fossil
mkdir /tmp/maybe && cd /tmp/maybe && fossil open /tmp/test.fossil
Etc...
The problem is that quite often these two sets are: changes I want to
commit (when they are ready), and changes I do not want to commit, but I
have to have in my working copy until I commit the first set.
Changelists help me to separate them and refer to each set by name,
rather than by naming each file every time I need to do something - get
status, check diff and so on.
For example, let's suppose I work on a bug. I have some local changes
to Makefile to, say, disable some components to speed up the build. I
want to have have those changes in my checkout even after I'm done with
the bug. I also have some changes in state_machine.c to make bug to
appear every time I start the program. I do not want to commit it, but
I do not need to keep it after I'm done:
$ fossil cl add build Makefile
$ fossil cl add tmp state_machine.c
$ fossil cl add bug300 state1.c state2.c
$ fossil status
--- Changelist build
EDITED Makefile
--- Changelist tmp
EDITED state_machine.c
--- Changelist bug300
EDITED state1.c
EDITED state2.c
$ fossil diff --cl bug300
$ ...
hack-hack-hack
...
$ fossil status
$ fossil add bug300 state3.c
$...
hack-hack-hack
...
$ fossil status
--- Changelist build
EDITED Makefile
--- Changelist tmp
EDITED state_machine.c
--- Changelist bug300
EDITED state1.c
EDITED state2.c
EDITED state3.c
$ fossil diff --cl bug300
$ fossil commit --cl bug300
$ fossil revert --cl tmp
Working on the change I am about to commit, I can easily end up having
10 or 20+ files, if I have to, say, refactor an interface, add extra
parameter to a widely used function and so on.
svn cl syntax is inconsistent, but I root for the idea to label
connected files for the commit/review purpose and I would love to have
something like that in Fossil
By ``label connected files'' I assume you mean related changes. If
you're already doing the above suggestion, there's always the option to
stash the changes.
That's true, I could stash changes, but that is not best solution.
Without change lists, I can not visually separate my temporary changes
when I look at status output. And when I check the diff, I do not want
my to see my temporary changes. Here changelists really help because of
the name you give to that group of files. Compare
$fossil diff --cl bug300
to
$fossil diff state1.c state2.c state3.c
Nikita
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
