partial commits

[Wagner Bruna]

Hello,

Edward Peschko wrote:
> Ok, fine - changesets are the master, changesets are the
> alpha and the omega, etc. etc. etc.
>
> Great - there is such a thing as set logic, as well, ie:
>
> IF my set of files has any overlap with change sets 1,2,3
> on the server, abort with error.
>
> IF my set of files has *no* overlap, then process successfully.

Checking for overlapping changes is not enough to ensure a successful
automatic merge, if you have interdependent files on your repository.
Consider:

- Alice changes a function on a.c, so it now calls b(int) from b.h;

- Before she finishes, Bob changes b(int) to b(int, int) on b.h and
b.c, and send his changes to the remote repository;

- Alice send her changes. They don't overlap with Bob's work, so the
server automatically merges them, breaking the build.

Some popular VCSs work exactly like this. Mercurial takes a safer
approach: all merges must be done locally, so the user has the chance
to verify and approve the results.

> Well, it's hard to check my workflow when everybody else at my
> company is at .94. Even if I get attic working (see above) I'll
> probably just use it for the patch functionality and default back
> to 94 for committing, etc.

If you don't mind extra heads on your local repository, you can store
away your local changes with plain 0.9.4: just make a separate
temporary commit. Something like:

# get remote changes
hg pull
# mark parent to get back to it afterwards
hg tag -l beforeallchanges
# commit *all* files, and mark the new temporary changeset
hg ci -m 'temporary commit, do not push this to remote'
hg tag -l file1file2file3
# update back, get the three changed files
hg up beforeallchanges
hg revert --all --no-backup -r file1file2file3
# and merge them with the remote changes
hg up tip
# verify changes (hg diff, make, test...)
# commit file1 and push
hg ci -m 'changes to file1' ./file1
hg push -r tip
# get back to work on file2 and file3

For simplicity, I'm assuming you didn't make other changesets after
the last pull, but it would work practically the same way if you did.
It's also possible (and IMHO better) to revert only file1 at first,
test it separately, and get back file2 and file3 changes afterwards
(the same way: update to parent revision, get changes with revert,
update to tip).

Hope that helps,
Wagner