Re: [Monotone-devel] New project: libmtn

[Justin Patrin]

On 7/4/06, Daniel Carosone <address@hidden> wrote:
> On Tue, Jul 04, 2006 at 05:50:56PM +0400, Arseny Nasokin wrote:
> >
> > Yes, I know it, but I can't edit revision at that case: I must
> > create backward mtn-diff for several files and create new revision
> > :( And for added/dropped files I should disapprove all and commit it
> > again. It's too mad when time is critical
>
> If I understand correctly what I *think* you're saying about your
> requirements here, you may need to seriously consider whether monotone
> is suited for them at all.
>
> No amount of refactoring into libraries is going to change the
> fundamental premise that, once committed (and distributed), a
> historical revision cannot be altered.
>
> That still leaves open the question of whether you really need to edit
> historical revisions, or whether instead your desire to do so is
> because of some other lack in the present monotone user interface: a
> more convenient way for you to instruct monotone to create new
> revisions with the changes you need, mostly automatically.  I suspect
> the latter, because your comments about 'when time is critical'
> suggest you're looking for a more expedient interface, rather than a
> fundamental capability.

A quick thought on this. A simple script could pull a diff for a
single file between two revisions, apply it, and commit it. Something
which you may find useful is a simple script I wrote a few weeks ago
called mtnpatch:
http://oe.reversefold.com/mtnpatch.py.txt

It takes monotone diff output and applies the patch, including
renames, deletes, and additions. You could write a simple script to
diff between revisions for a single file (or a collection of files),
then run mtnpatch on the patch, then commit it with specific
information.

FYI, the above script is meant for use in cherry-picking (until
monotone supports this itself). I plan to create a wrapper script for
it sometime soon to pull a diff for a revision, patch the working
copy, and prepopulate the commit message with relevant info. If anyone
has any clever ideas on how to do this or how to mark the
cherry-picked revision I'd be grateful. (just commit-message, a
special cert which says what rev was picked, etc).

> Could you paint a longer scenario of the situation where you think
> editing the revision is necessary?  Perhaps also describe how you
> would solve this situation if you had the luxury of time, and why
> that's too slow or labour-intensive?  That would help me understand
> your concerns a lot better.


--
Justin Patrin