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

[Thomas Keller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ralf S. Engelschall schrieb:
>     $ mtn ci -m "description of logical change1" file11:-2,-4 ... file1N
>     $ mtn ci -m "description of logical change2" file21:+2,+4 ... file2N
>     $ mtn ci -m "description of logical change3" file31       ... file3N
> 
> The particular syntax doesn't matter very much. Every syntax is better
> than all the time having to do the manual dance mentioned above.

I have to agree that one pretty often faces such things, "oh, I forgot
to indent that here properly" or "let me fix this real quick", while
being in the mid of a bigger change. Doing a fresh checkout of the base
revision, making the change there, commit and update/merge the original
workspace is possible, of course, but takes too long and I'm lazy ;)

But the proposed solution also seems very complex to me, because one
would have to address the hunks indidivually by number and internally
screw around with that as well (I have no idea how exactly mtn's
internal delta algorithm works, but I highly doubt that it would be easy
to teach him understanding diff hunk numbers).

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.cpp
$ mtn diff --stack 1
<output the differences for first stack>
$ mtn ci --stack 2
<commit changes from the second stack>

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.

Depending on the stack number N given, diff would either diff baserev <>
N for N=1 or N-1 <> N.

mtn ci --stack N is a bit trickier. At first it would have to back out
everything what happened after N (N + 1, N + 2, ...) and commit only
that. And if we want to allow N+1 to be committed, before N is
committed, it becomes even more trickier.

Hrm... maybe the idea is not that good. I currently have no idea how to
produce appliable/valid patches for stacks like this, especially because
the file offsets would have to be rewritten constantly. I have to think
more about that.

Thomas.

- --
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHjNWeaf7NlBYNEJIRAhPwAJ9r19gk5AaIR/r9U/3hMgrc27C+xACg+1T1
z9AxwEVfzN6ALL67qDQKEJs=
=qKBq
-----END PGP SIGNATURE-----