Hi Warren,
On 10/21/2016 07:21 PM, Warren Young wrote:
On Oct 21, 2016, at 7:31 PM, Nikita Borodikhin <[email protected]> wrote:
I would like to be able to commit only needed changes:
So say:
$ fossil ci Makefile state_machine.c
It’s actually less typing than defining a changelist and then committing the
changelist.
If you’re not certain about the changes in those two files, you can “fossil
diff” just those two files:
$ fossil diff Makefile state_machine.c | less
Then edit the command from history to change “diff” to “ci” when you’re
satisfied.
The difference here is that I define _name_ for the _group of files_
upfront. I can do some iterations of change-check_status-view_diff
before I commit the change, and it helps me a lot to see my files
grouped in the output of status. Again, example I had is very simple,
but imaging I have twenty files changed because of renamed interface.
When I look at status output, I can check two parts: my change set, to
make sure it does not have anything unneeded, and the rest of it, to
make sure it does not have any of my changed files missing from the
changelist. Without changelists - well, it is possible, but it less
convenient (you have to list files every time you do something) and more
error-prone.
Here’s the alternative with branches:
$ fossil ci --branch my-new-feature state1.c
$ fossil up trunk
$ fossil ci --branch my-other-new-feature state2.c
$ fossil up trunk
$ fossil ci
It’s a bit more complex, but has a different effect, so you can’t compare them
apples-to-apples. Here, we’re saying that state1.c and state2.c contain
partially finished features which we want to set aside so that we can focus on
Makefile and state_machine.c. Maybe we’ll make more changes before checking
the changes in.
You can use the stash instead if you don’t like branches:
$ fossil stash save state1.c
$ fossil stash save state2.c # yes, separate commands!
$ fossil ci
It’s simpler in that you don’t have to keep returning to trunk to revert the
changes, but if you’re working on a team, now you have the Guy In the Room
Problem:
https://www.youtube.com/watch?v=oY6BCHqEbyc
If you’re not working on a team, the main disadvantage of the stash over
branches is that it’s local to a particular open checkout, so that if you’re
working on multiple machines or have multiple checkouts, you can’t simply
switch branches to see your in-progress feature, you have to somehow copy the
files over manually.
Another problem with the stash is that if you say “fossil close,” it will offer
to throw away your stash, which is irrecoverable if you accept. At least with
branches, you have a copy of the code durably archived.
There’s no shame in having partially-working code checked in on a branch.
Broken code on the trunk is a problem for many reasons, but it’s quite common
to make many checkins on a branch to bring the initial checkin on that branch
into shape suitable for merging back into the trunk.
I like and use branches, but they do not solve the problem changelists
solve. The problem is: I often have two sets of changes in my local
checkout. One set is supposed to go into branch and, eventually, into
trunk, and the other set consists of my local changes to help me work on
that piece of code. That other set should not get into repository. I
could have committed it and undo that commit before the merge back to
trunk, but sometimes I would forget to do that.
I have that problem that often, so I wrote a wrapper that demands
specifying changelist to svn commit.
Changelists help me to:
* isolate those groups of files
* work with groups using names of the group rather than files one by one
* evolve the group alongside with my work, adding files into it, until
change set is ready to be committed
Nikita
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
