Re: [Monotone-devel] Perhaps strange request: partial per-file commit

[Derek Scherger]

Thomas Keller wrote:
> So, what could one do instead? Maybe it would be a good idea to record
> different patch sets somehow differently:
>
> $ vi some_file.cpp
> $ mtn stack some_file.cpp
> $ vi some_file.cpp
> $ vi other_file.cpp
> $ mtn stack some_file.cpp other_file.cpp
> $ mtn ls stacks
> 1: changed some_file.cpp
> 2: changed some_file.cpp, other_file.cppluck
> $ mtn diff --stack 1
> <output the differences for first stack>
> $ mtn ci --stack 2
> <commit changes from the second stack>

I've thought of this in terms of fictional suspend/resume commands (not 
to be confused with the recent suspend cert command which means I need 
to think of new names), call them pause and resume for now.

> How would that work exactly? If somebody puts something on a stack, a
> new patch is generated between the base revision and the current
> workspace contents. If another stack is created upon, only the changes
> between the first and the second stack are recorded - but only if the
> changes do not overlap, otherwise it would bail out.

The idea I had in mind would be something like, commit the current 
revision to your local db *without* a branch cert, but perhaps with some 
other paused cert that gives a name to each paused revision. This commit 
would be done by the pause command. After committing the paused 
revision, *don't* update _MTN/revision to the new rev, but rather revert 
the pending changes, which are now safely in the database and go back to 
the base revision. From here you can make some other, unrelated change, 
commit that and then resume the previously suspended change. Resume 
would work something like update or pluck, but again, without making 
changes to _MTN/revision so that the workspace continues to be based off 
of whatever revision it is currently at.

The paused revisions would never have children and would not have branch 
certs and would not be synced via netsync. Ideally, the resume command 
would remove the paused revision from the database entirely, but this is 
a bit finicky.

Others have a mentioned that such a feature would be useful with really 
big workspaces as well. Rather than checking out another workspace to 
make an unrelated change, suspend the current one, make the other change 
and then resume where you left off.

Cheers,
Derek