Re: [Monotone-devel] Re: Undo a commit

[Thomas Keller]

Brian May schrieb:
> Thomas Keller wrote:
>> I'd do it "safely" without messing around with _MTN/revision and move
>> the current changes aside to re-apply them later on:
>>
>> $ mtn diff > current_changes.txt
>> $ mtn revert .
>> $ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
>> $ patch -p0 < current_changes.txt
>>   
> Unfortunately it won't work if you have renamed files, for example.

Yeah, I know, I know. The same goes out for attributes. But as I said
earlier, I really would like to have an mtn patch command, which would
solve these issues. Still, the proposed workflow works reasonable well
for small changes in existing files.

Thomas.

-- 
GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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



signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Brian May]

Thomas Keller wrote:

I'd do it "safely" without messing around with _MTN/revision and move
the current changes aside to re-apply them later on:

$ mtn diff > current_changes.txt
$ mtn revert .
$ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
$ patch -p0 < current_changes.txt
  

Unfortunately it won't work if you have renamed files, for example.

I really liked the tla undo/redo options. I found some documentation here:



Brian May


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Ludovic Brenta]

Daniel Carrera <[EMAIL PROTECTED]> writes:
> Ludovic Brenta wrote:
>> Easier:
>>
>> $ mtn rebase p:
>>
>>> $ mtn disapprove 1e129601c2cd983fc6c73053cc13544ac36cc229
>>
>> $ mtn disapprove h:
>
> Are p: and h: aliases for parent and head? That *is* easier.

Yes.  See the chapter "Selectors" in the monotone manual.

> mtn rebase p:
> mtn disapprove h:
>
> Very nice. Now, so that I'm clear, what exactly is h:/head? If you
> "rebase", does that change the head?

No, it only changes the revision on which the current workspace is
based.  Other workspaces are unaffected.  The database is unaffected.

> If not, then what happens when a
> branch has two heads? What would h: mean in that case?

In that case, monotone complains and bails out; you have to select one
of the heads unambiguously.

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Ludovic Brenta wrote:

Easier:

$ mtn rebase p:


$ mtn disapprove 1e129601c2cd983fc6c73053cc13544ac36cc229


$ mtn disapprove h:


Are p: and h: aliases for parent and head? That *is* easier.

mtn rebase p:
mtn disapprove h:


Very nice. Now, so that I'm clear, what exactly is h:/head? If you 
"rebase", does that change the head? If not, then what happens when a 
branch has two heads? What would h: mean in that case?



Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Ludovic Brenta]

Daniel Carrera <[EMAIL PROTECTED]> writes:
> ## Oops, I made a mistake.
>
> $ mtn log|grep Ancestor|head -n 1
> |   Ancestor: 4b4069fffd06d8f4c5981314d99838bda9a9b75a
>
> $ mtn rebase 4b4069fffd06d8f4c5981314d99838bda9a9b75a

Easier:

$ mtn rebase p:

> $ mtn disapprove 1e129601c2cd983fc6c73053cc13544ac36cc229

$ mtn disapprove h:

> It's not as simple as "mtn undo" but it's good enough.

Yes.

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Daniel Carrera wrote:
Ok. "mtn suspend" and "mtn disapprove" look like good solutions. 
Combined with "mtn rebase" that would cover my use case.


Actually, it looks like "suspend" is used to suspend certs rather than 
revisions. But that's ok, I still have "disapprove".


$ mtn commit
mtn: beginning commit on branch 'com.foo'
mtn: committed revision 1e129601c2cd983fc6c73053cc13544ac36cc229

## Oops, I made a mistake.

$ mtn log|grep Ancestor|head -n 1
|   Ancestor: 4b4069fffd06d8f4c5981314d99838bda9a9b75a

$ mtn rebase 4b4069fffd06d8f4c5981314d99838bda9a9b75a

$ mtn disapprove 1e129601c2cd983fc6c73053cc13544ac36cc229



It's not as simple as "mtn undo" but it's good enough.

Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Ludovic Brenta wrote:

The command "db kill_rev_locally" is long so I don't like it. What
would be the consequences of a divergence? Is it ok if I simply run
"mtn rebase" and then go on merrily on my way making my other
branches? If so, then I would be entirely happy with rebase.


After "mtn rebase p:", there are two ways you could create a
divergence:

$ mtn commit

creates a second head in the same branch; later on, "mtn checkout",
"mtn update" and other commands will complain that there are two heads
and require you to select a head manually.  You can resolve that
either with "mtn merge", "mtn suspend" or "mtn disapprove"; it's up to
you.  This is sometimes called "light-weight" branching; it is
appropriate for short-lived divergences that you intend to resolve at
one point in the future.


Ok. "mtn suspend" and "mtn disapprove" look like good solutions. 
Combined with "mtn rebase" that would cover my use case.




The second way is:

$ mtn commit -b new_branch


I don't like this solution as much. I don't want to change branch name 
every time I goof off a commit. I'm happy with suspect or disapprove.


So... who do we need to convince to get "mtn rebase"? Do you think that 
one could be done with a Lua hook? I know I can write a Perl script to 
do it, but a Lua hook feels like the right way to do it.


Cheers,
Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Ludovic Brenta]

Daniel Carrera writes:
> mtn rebase 

OK, that's an improvement on my proposal.

> The command "db kill_rev_locally" is long so I don't like it. What
> would be the consequences of a divergence? Is it ok if I simply run
> "mtn rebase" and then go on merrily on my way making my other
> branches? If so, then I would be entirely happy with rebase.

After "mtn rebase p:", there are two ways you could create a
divergence:

$ mtn commit

creates a second head in the same branch; later on, "mtn checkout",
"mtn update" and other commands will complain that there are two heads
and require you to select a head manually.  You can resolve that
either with "mtn merge", "mtn suspend" or "mtn disapprove"; it's up to
you.  This is sometimes called "light-weight" branching; it is
appropriate for short-lived divergences that you intend to resolve at
one point in the future.

The second way is:

$ mtn commit -b new_branch

The divergence is then "permanent"; you now have two branches with one
head each; monotone will not complain about that.  You can still merge
whenever you want with "mtn propagate".  This is sometimes called
"heavy-weight" branching and is for intentional divergences that you
think should live for a while (e.g. stable/maintenance
vs. unstable/development).

Note that "heavy-weight" is not that heavy; the only difference is the
value of the "branch" cert.  So "heavy-weight" does not consume any
additional space in the database compared to "light-weight"; but it
does consume from the branch namespace.

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Bruce Stephens wrote:

Ludovic Brenta <[EMAIL PROTECTED]> writes:

I would prefer a single-purpose command, "mtn rebase -r ", that only
rewrites the old_revision field in _MTN/revision...


That's not what "git rebase" does.  It's exactly (modulo changes to
the index, which I guess don't apply to monotone) what "git reset"
does (with --mixed, which is the default).

(Perhaps "rebase" is a suitable name for this; git's not particularly
consistent with anything else (in particular "git revert" does what
"mtn disapprove" does, which causes confusion occasionally).)


I think "rebase" is a good name for Ludovic's solution. Monotone already 
has the concept of "base revision" (e.g. get_base_revision_id) and 
"rebase" sounds like "change base revision". So it would be internally 
consistent. In turn, to me "reset" send a very different message.


Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Ludovic Brenta wrote:

Step 1: Edit _MTN/revision to point to the previous revision.
Step 2: Run kill_rev_locally on the last revision.


I would prefer a single-purpose command, "mtn rebase -r ", that only
rewrites the old_revision field in _MTN/revision.  Then, the user can
either kill_rev_locally h:, disapprove h:, or simply commit to create a
divergence if that's what they want.


I could go for that. I like uncommit/rollback but rebase is good too. I 
would remove the -r flag:


mtn rebase 

The command "db kill_rev_locally" is long so I don't like it. What would 
be the consequences of a divergence? Is it ok if I simply run "mtn 
rebase" and then go on merrily on my way making my other branches? If 
so, then I would be entirely happy with rebase.


Cheers,
Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Atallah]

On Fri, Oct 10, 2008 at 6:41 AM, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> Ludovic Brenta wrote:
>>>
>>> Of course we could teack kill_rev_locally also to accept workspace
>>> changes and essentially do a workspace merge for these cases, but I'm
>>> not sure if there is really a use case for this which is worth to mess
>>> with that.
>>
>> Or teach db kill_rev_locally to only change the workspace's parent
>> revision without changing anything to the workspace?
>
> Or make a command "mtn rollback" that is equivalent to kill_rev_locally
> without changing the workspace. It should be simple enough.
>
> Step 1: Edit _MTN/revision to point to the previous revision.
> Step 2: Run kill_rev_locally on the last revision.

One thing that I haven't seen mentioned in these conversations about
"kill_rev_locally" (perhaps I glossed over it) is someone explicitly
noting that if the revision in question has already been pushed to
another DB, a pull from that DB will restore the revision.  There is
no way (for good reason) to cause a revision to be removed from remote
databases.

With this in mind, I think it doesn't make sense to make a "rollback"
command, but arguably an option for "kill_rev_locally" to change the
behavior slightly is worthwhile.

-D


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Thomas Keller]

Ludovic Brenta schrieb:
> Selon Thomas Keller:
>> Ludovic Brenta schrieb:
>>> Or teach db kill_rev_locally to only change the workspace's parent
>>> revision without changing anything to the workspace?
>> This is what I meant with "workspace merge" - of course the parent of
>> the current workspace no longer exists if it is killed, so
>> old_revision
>> gets rewritten to the parent of the killed revision. Then, the killed
>> revision's changeset is merged (plucked?) into this altered workspace.
> 
> That last step is unnecessary because the workspace already contains the
> changes in the killed revision.

Right, wrong wording: its not merged into the altered workspace, but
into the workspace' _MTN/revision (after all f.e. a previously added
file has to be marked as "added" again there).

-- 
GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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




signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Ludovic Brenta]

Selon Thomas Keller:
> Ludovic Brenta schrieb:
> > Or teach db kill_rev_locally to only change the workspace's parent
> > revision without changing anything to the workspace?
> 
> This is what I meant with "workspace merge" - of course the parent of
> the current workspace no longer exists if it is killed, so
> old_revision
> gets rewritten to the parent of the killed revision. Then, the killed
> revision's changeset is merged (plucked?) into this altered workspace.

That last step is unnecessary because the workspace already contains the
changes in the killed revision.

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Ludovic Brenta wrote:

Only partially; in your test you lost the fact that you added file
"asdf":


Yes, indeed. I noticed but forgot to mention it. If that was the only 
issue I would be satisfied. But in your last post you noted other issues 
with "revert" approach (moving files, deleting files), so I'm not as 
confident about that approach.


In my most recent email I suggested a new "mtn rollback" command that 
uses your solution. Perhaps "mtn uncommit" is a better name. Some people 
may expect "rollback" to do what "revert" does.


Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Ludovic Brenta wrote:

Of course we could teack kill_rev_locally also to accept workspace
changes and essentially do a workspace merge for these cases, but I'm
not sure if there is really a use case for this which is worth to mess
with that.


Or teach db kill_rev_locally to only change the workspace's parent
revision without changing anything to the workspace?


Or make a command "mtn rollback" that is equivalent to kill_rev_locally 
without changing the workspace. It should be simple enough.


Step 1: Edit _MTN/revision to point to the previous revision.
Step 2: Run kill_rev_locally on the last revision.


What do you think?


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Ludovic Brenta]

Selon Daniel Carrera <[EMAIL PROTECTED]>:
> Hi Thomas. I tried this and it looks like the diff/patch step is 
> unnecessary - and indeed, if you run patch you actually break the 
> workspace. It appears that 'mtn revert .' is enough to solve the
> problem with kill_rev_locally.

Only partially; in your test you lost the fact that you added file
"asdf":

> % mtn add asdf
> mtn: adding asdf to workspace manifest
[...]
> % mtn revert .
[...]
> % mtn db kill_rev_locally 3be3ed81bd01509d0c1e2db46e987b1040bbc222
> mtn: applying changes from 3be3ed81bd01509d0c1e2db46e987b1040bbc222 on
> the current workspace
> % mtn status
> Current branch: foo.sandbox.branch
> Changes against parent 9f79e6063616d8fb85cad56253e39c2c49927899
>patched  foo

Now you have to "mtn add" the new file again.

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Ludovic Brenta]

Selon Thomas Keller <[EMAIL PROTECTED]>:
> I'd do it "safely" without messing around with _MTN/revision and move
> the current changes aside to re-apply them later on:
> 
> $ mtn diff > current_changes.txt
> $ mtn revert .
> $ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
> $ patch -p0 < current_changes.txt

The problem with this "safe" approach is that it is unsafe in the presence
of new, moved or deleted files.

A new but uncommitted file will appear as a hunk in the diff, it will
survive the "mtn revert .", and applying the diff will double its
length.

A moved file will actually not appear in the diff at all, except as a
comment; reapplying the diff will lose that change.

A deleted file may appear as a hunk in the diff (I'm not sure anymore; it
may also appear only as a comment) in which case reapplying the diff will
not delete the file, only make it empty.

> Of course we could teack kill_rev_locally also to accept workspace
> changes and essentially do a workspace merge for these cases, but I'm
> not sure if there is really a use case for this which is worth to mess
> with that.

Or teach db kill_rev_locally to only change the workspace's parent
revision without changing anything to the workspace?

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Thomas Keller wrote:

Ludovic Brenta schrieb:

That's where my trick comes in: manually edit _MTN/revision without
changing anything else in your workspace, then kill the head revision.


I'd do it "safely" without messing around with _MTN/revision and move
the current changes aside to re-apply them later on:

$ mtn diff > current_changes.txt
$ mtn revert .
$ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
$ patch -p0 < current_changes.txt



Hi Thomas. I tried this and it looks like the diff/patch step is 
unnecessary - and indeed, if you run patch you actually break the 
workspace. It appears that 'mtn revert .' is enough to solve the problem 
with kill_rev_locally.


Here is a test:

-- START EXAMPLE
## Start with no changes.
% ls
_MTN/ foo
% mtn status
Current branch: foo.sandbox.branch
Changes against parent 9f79e6063616d8fb85cad56253e39c2c49927899
  no changes


## Make changes.
% echo "platypus" > foo
% echo "platypus" > asdf
% mtn add asdf
mtn: adding asdf to workspace manifest


## Commit 'foo' (this is the wrong commit).
% mtn commit foo
mtn: beginning commit on branch 'foo.sandbox.branch'
mtn: committed revision 3be3ed81bd01509d0c1e2db46e987b1040bbc222


## OOps - wrong commit.
% mtn revert .
% mtn db kill_rev_locally 3be3ed81bd01509d0c1e2db46e987b1040bbc222
mtn: applying changes from 3be3ed81bd01509d0c1e2db46e987b1040bbc222 on 
the current workspace



## Ok, so *now* I should be exactly where I started.
% mtn status
Current branch: foo.sandbox.branch
Changes against parent 9f79e6063616d8fb85cad56253e39c2c49927899
  patched  foo
% ls
_MTN/ asdf  foo
% cat asdf
platypus
-- END EXAMPLE

If I add the diff/patch step then 'cat asdf' shows that there are *two* 
lines of "platypus" in asdf.



Cheers,
Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Ludovic Brenta wrote:

That's where my trick comes in: manually edit _MTN/revision without
changing anything else in your workspace, then kill the head revision.


Ok. So let's see that process again:


## Current revision: aa

$ mtn commit

## Current revision: bb
## Ooops, wrong commit.

$ vi _MTN/revisions  ## Edit this file.

$ mtn db kill_rev_locally bb



Did I get it right? Now, how do I edit _MTN/revisions? It appears to 
contain 2-3 hashes:


% cat _MTN/revision
format_version "1"

new_manifest [b271905b34a9287cf767d09096f01b765ca17ecd]

old_revision [dcfbf59823cf21e292b60ba8f8463f65ea383597]

add_file "foo"
 content [da39a3ee5e6b4b0d3255bfef95601890afd80709]


When I run mtn status I see the same hash as old_revision. So in my 
example above I would set old_revision to aa. But what do I do 
with the other hashes?



Thanks,
Daniel.



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Thomas Keller]

Ludovic Brenta schrieb:
> Selon Daniel Carrera <[EMAIL PROTECTED]>:
>> Daniel Carrera wrote:
>>> So I am clear, the entire command is "mtn db_kill_rev_locally" and 
>>> that's it? If we convinced the devs to make "mtn uncommit" an alias to
> 
>>> "mtn db_kill_rev_locally" would that cover my use case?
>> I just tried this on a sandbox branch and it doesn't work that well. In
>>
>> particular, it fails if there are any uncommitted changes:
>>
>> % mtn status
>> Current branch: foo.sandbox.branch
>> Changes against parent dcfbf59823cf21e292b60ba8f8463f65ea383597
>>addedfoo
>>
>> % mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
>> mtn: misuse:
>> Cannot kill revision dcfbf59823cf21e292b60ba8f8463f65ea383597, because
>>
>> it would leave the current workspace in an invalid state, from which 
>> monotone cannot recover automatically since the workspace contains 
>> uncommitted changes. Consider updating your workspace to another 
>> revision first, before you try to kill this revision again.
>>
>>
>>
>> This is not good. Suppose I have edited files Foo1, Foo2 and Bar. I run
>>
>> "mtn commit Foo1" because I forgot about Foo2. So I decide I want to 
>> undo that last commit so I can run "mtn commit Foo1 Foo2" which is what
>>
>> I wanted initially. Monotone won't let me do it because file Bar has 
>> changes.
> 
> That's where my trick comes in: manually edit _MTN/revision without
> changing anything else in your workspace, then kill the head revision.

I'd do it "safely" without messing around with _MTN/revision and move
the current changes aside to re-apply them later on:

$ mtn diff > current_changes.txt
$ mtn revert .
$ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
$ patch -p0 < current_changes.txt

Of course we could teack kill_rev_locally also to accept workspace
changes and essentially do a workspace merge for these cases, but I'm
not sure if there is really a use case for this which is worth to mess
with that.

What kill_rev_locally is really useful for right now is...

$ mtn ci foo bar/baz
[enter log message]
[revision committed]
"oh fuck, I forgot one file!", "oh fuck, I forgot to describe a change!"
$ mtn db kill_rev_locally 
$ mtn ci foo bar/baz bla
...

In my opinion, for all other use cases people should actually work with
 disapprove + merge, since this also allows to redo changes when there
already exist children to the bad revision.

Thomas.

-- 
GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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




signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Nathaniel Smith]

On Thu, Oct 9, 2008 at 5:19 PM, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> I don't care much about the database behaviour. What I meant to say earlier
> is that I'm happy with whatever choice the devs make. I only really care
> about the workspace (not losing my work).

It's worth noting that with 'disapprove', your work isn't lost -- the
original commit is still in the database, where you accidentally put
it.  It can be seen with 'mtn log', 'mtn diff', etc.  You also have
the option of putting the changes it made into your workspace using
the 'mtn pluck' command.

Basically, 'mtn pluck -r FROM -r TO' takes whatever differences there
are between the revision FROM and the revision TO and applies them to
your workspace as edits.  'mtn diff -r FROM -r TO' will show you
exactly what changes it will apply.  So in this case you could do 'mtn
pluck -r THE_ACCIDENTAL_REVISION -r THE_DISAPPROVE_REVISION'.

-- Nathaniel


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Daniel Carrera wrote:
So I am clear, the entire command is "mtn db_kill_rev_locally" and 
that's it? If we convinced the devs to make "mtn uncommit" an alias to 
"mtn db_kill_rev_locally" would that cover my use case?


I just tried this on a sandbox branch and it doesn't work that well. In 
particular, it fails if there are any uncommitted changes:


% mtn status
Current branch: foo.sandbox.branch
Changes against parent dcfbf59823cf21e292b60ba8f8463f65ea383597
  addedfoo

% mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
mtn: misuse:
Cannot kill revision dcfbf59823cf21e292b60ba8f8463f65ea383597, because 
it would leave the current workspace in an invalid state, from which 
monotone cannot recover automatically since the workspace contains 
uncommitted changes. Consider updating your workspace to another 
revision first, before you try to kill this revision again.




This is not good. Suppose I have edited files Foo1, Foo2 and Bar. I run 
"mtn commit Foo1" because I forgot about Foo2. So I decide I want to 
undo that last commit so I can run "mtn commit Foo1 Foo2" which is what 
I wanted initially. Monotone won't let me do it because file Bar has 
changes.


:-(


Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Lapo Luchini wrote:

So what you actually needed was something that had the
workspace-behaviour of "db kill_rev_locally" (i.e. putting the workspace
"just like it was a second before previous commit")


Yes.


but the
database-behaviour of "disapprove" (a commit that reverts the previous
one), is that so?


I don't care much about the database behaviour. What I meant to say 
earlier is that I'm happy with whatever choice the devs make. I only 
really care about the workspace (not losing my work).




IMHO in this use-case what you want to use is *REALLY* the good old
"db kill_rev_locally". It is meant exactly for *that* (un-committing
something *just after* it was committed by error).

Or at least, that what I do in those (quite frequent) cases I do a wrong
commit ;-)


Ok.

So I am clear, the entire command is "mtn db_kill_rev_locally" and 
that's it? If we convinced the devs to make "mtn uncommit" an alias to 
"mtn db_kill_rev_locally" would that cover my use case?





If your "wrong commit" was already propagated on other servers, it's
more complex (as you should track them all down), so it's probably
better to disapprove and manually reconstruct the workspace state (e.g.
NOT updating to the "disapprove"-generated revision but instead changing
_MTN/options to just *be* that revision while keeping the content of the
disapproved commit).


Yes. I wouldn't try to uncommit if the changes had already been propagated.


Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Lapo Luchini wrote:

But using disapprove you actually did not "un-commit", you really wanted
a commit that had the previous state (again)... so if the previous one
had "add directory, add file", this one gets "delete file, delete
directory"... it's correct that way, because that's what the "new
revision" wants to do over the previous one...

I think the problem is you wanted to do an "un-commit" and that doesn't
really exist(except, with proper care, "db kill_rev_locally", which does
exactly that: even restores the workspace state in the same state it was
before the commit) and what you ended up doing is something really
different... it's a matter of expectations, IMHO, and not some inherent
"wrongness" in the "mtn update" behaviour.


I can see the argument about "mtn update". In general, "mtn update" 
means "change the files on this directory to match what is on the DB". 
So I don't blame "mtn update" for changing the files. I think that the 
problem is with "mtn disapprove" and the fact that after I ran mtn 
disapprove I could not run "mtn commit" again to get my changes 
committed the right way.


I'm not sure that I agree that the problem is that there is no un-commit 
with Monotone. I don't object to Monotone recording the fact that I made 
a wrong commit and decided to reverse it. I only object to not being 
able to do the correct commit later. This is how I was expecting "mtn 
disapprove" to work:


mtn commit

## Oops, I commited Foo and Bar but I only meant to commit Foo.

mtn disapprove  ## A commit that says "cancel the last commit".

mtn commit ## THIS time I get only Foo like I originally intended.


I think that this is sensible. "mtn disapprove" changes the DB to note 
the fact that I reversed the last commit and now I can make a new 
commit. In the database, the above would be recorded like this:


* daniel committed Foo an Bar
* daniel reversed the commit of Foo an dBar
* daniel committed Foo


In other words, I don't think "mtn update" did anything wrong, but I 
think that "mtn disapprove" did something wrong by forcing me to run 
"mtn update" for no obvious reason. I don't object to keeping a history 
showing that I committed something and then I changed my mind. And you 
could argue that this is better than altering the history. But I do 
object to losing my work because I a wrong commit cannot be reversed 
without running the destructive "mtn update".



Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Thomas Keller]

Bruce Stephens schrieb:
> In monotone the nearest is "mtn db kill_revision_locally ..."  but I'm
> not sure whether the workspace is left in a useful state.  I fear it's
> left pointing at a (now) nonexistent revision?

No, I've implemented a couple of months ago that changes are re-applied
to a workspace if its base revision is killed and db kill_rev_locally is
executed inside this workspace.

One of the reasons why I did that was because this "unuseful" state
monotone was previously in.

Thomas.

-- 
GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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



signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Ludovic Brenta wrote:

# Oops, I made a mistake and I want to take that revison out

$ mtn log --last=1
Copy the parent revision
$ vi _MTN/revision
Replace the current revision with its parent
$ mtn db kill_rev_locally h:some_branch

And I'm happy.


Thanks. I have bookmarked your instructions.

It would be nice if Monotone had a command for this. For example, "mtn 
undo" or "mtn uncommit". Naturally, it should give ask to confirm that 
you really want to do this.


How do the developers feel about a feature like this one?

Cheers,
Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Ludovic Brenta]

Daniel Carrera <[EMAIL PROTECTED]> writes:
> Ludovic Brenta wrote:
>> This is easy to do in a workspace: rm -f $(mtn ls unknown)
> 
> It would be even better if I didn't have to delete these files. Just
> because Monotone is not tracking them doesn't mean that they are not
> useful. My TODO list, a library, a quick test file, etc. Those are all
> legitimate reasons to have files that are not tracked.

Yes indeed; that's why monotone will not delete these "unknown" files
under any circumstances.  The problem you had was that "mtn update"
needed to replace "unknown" files with "known" files; monotone
preferred to bail out rather than overwrite the "unknown" files that
were in the way.

> Over-all I am concerned about the process of un-doing a commit. What
> I want is a functional equivalent of Monotone acting as if I had not
> done the commit yet. I don't want it to nuke my files or revert my
> changes.

To achieve this, revert your workspace to the previous revision first,
then "mtn db kill_rev_locally" the offending (head) revision.

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Ludovic Brenta]

Daniel Carrera <[EMAIL PROTECTED]> writes:

> Daniel Carrera wrote:
>> So Monotone is expecting me to figure out which files it is not
>> tracking and remove those files before it'll update the working
>> directory? I can't have files or directories that monotone does not
>> keep track of? The "include/php" directory has an external php
>> library. No sense in having that in my monotone database.
>
> Indeed, that seems to have been the case. After making a backup of my
> certification directory I removed all the files that were not in
> Monotone. That includes the _darcs directory, hidden files, a library,
> test files, a TODO list, etc. Then I ran 'mtn update' and Monotone
> deleted everything. It deleted all the files and directories under the
> certification directory. It's ok because I had a backup, but it's not
> what I was hoping monotone would do.
>
> I'm not happy with what Monotone did. If I undo a commit, I don't want
> Monotone to delete or modify my files. If I wanted that I would have
> told it to revert. What I want is that Monotone remove that action
> from the database and then behave as if the commit had never
> happened. I don't want it to mess with my files unless I say 'revert'.

I have a workaround that I used many times already.

$ mtn checkout -b some_branch
$ edit at will
$ mtn checkin

# Oops, I made a mistake and I want to take that revison out

$ mtn log --last=1
Copy the parent revision
$ vi _MTN/revision
Replace the current revision with its parent
$ mtn db kill_rev_locally h:some_branch

And I'm happy.

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Derek Scherger wrote:
If that commit originally added the certification directory then you 
disapprove the commit it amounts to removing the certification 
directory. When you then say update monotone will remove the directory 
rather than leaving junk laying around. Monotone will refuse to remove 
the directory if that directory contains things it doesn't know about 
though, which is what you saw.


Yeah, but what if the commit *edits* a file. I undo the commit and 
monotone reverts the edits. That's not what I want. If I want that I'll 
run "mtn revert". The way Monotone acts, I lose my work.



Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Ludovic Brenta wrote:

So Monotone is expecting me to figure out which files it is not
tracking and remove those files before it'll update the working
directory?

Yes, when the update is trying to remove a directory containing such
files.


This is easy to do in a workspace: rm -f $(mtn ls unknown)


I wish I had known that command about 10 minutes ago :-)

Thanks, good to know for the future.

It would be even better if I didn't have to delete these files. Just 
because Monotone is not tracking them doesn't mean that they are not 
useful. My TODO list, a library, a quick test file, etc. Those are all 
legitimate reasons to have files that are not tracked.


Over-all I am concerned about the process of un-doing a commit. What I 
want is a functional equivalent of Monotone acting as if I had not done 
the commit yet. I don't want it to nuke my files or revert my changes.



Cheers,
Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Derek Scherger]

On Thu, Oct 9, 2008 at 11:20 AM, Daniel Carrera <[EMAIL PROTECTED]>wrote:

>
> I'm not happy with what Monotone did. If I undo a commit, I don't want
> Monotone to delete or modify my files. If I wanted that I would have told it
> to revert. What I want is that Monotone remove that action from the database
> and then behave as if the commit had never happened. I don't want it to mess
> with my files unless I say 'revert'.
>

If that commit originally added the certification directory then you
disapprove the commit it amounts to removing the certification directory.
When you then say update monotone will remove the directory rather than
leaving junk laying around. Monotone will refuse to remove the directory if
that directory contains things it doesn't know about though, which is what
you saw.

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Daniel Carrera wrote:
So Monotone is expecting me to figure out which files it is not tracking 
and remove those files before it'll update the working directory? I 
can't have files or directories that monotone does not keep track of? 
The "include/php" directory has an external php library. No sense in 
having that in my monotone database.


Indeed, that seems to have been the case. After making a backup of my 
certification directory I removed all the files that were not in 
Monotone. That includes the _darcs directory, hidden files, a library, 
test files, a TODO list, etc. Then I ran 'mtn update' and Monotone 
deleted everything. It deleted all the files and directories under the 
certification directory. It's ok because I had a backup, but it's not 
what I was hoping monotone would do.


I'm not happy with what Monotone did. If I undo a commit, I don't want 
Monotone to delete or modify my files. If I wanted that I would have 
told it to revert. What I want is that Monotone remove that action from 
the database and then behave as if the commit had never happened. I 
don't want it to mess with my files unless I say 'revert'.



Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Ludovic Brenta]

Bruce Stephens writes:
> Daniel Carrera writes:
>
> [...]
>
>> So Monotone is expecting me to figure out which files it is not
>> tracking and remove those files before it'll update the working
>> directory?
>
> Yes, when the update is trying to remove a directory containing such
> files.

This is easy to do in a workspace: rm -f $(mtn ls unknown)

-- 
Ludovic Brenta.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Thomas Keller wrote:

mtn: warning: cannot drop non-empty directory 'certification'
mtn: warning: cannot drop non-empty directory 'certification/include'
mtn: warning: cannot drop non-empty directory 'certification/include/php'
mtn: warning: cannot drop non-empty directory
'certification/templates/moderator'
mtn: misuse: 4 workspace conflicts


This is something we hopefully remove in the next release. Just move the
certification/ directory out of the way so monotone can cleanly update
your workspace to the previous revision.


Monotone didn't like that either. :-(  See below:


$ mv certification foo
$ mtn update
mtn: updating along branch 'org.theingots'
mtn: selected update target d02074eb70d2bdfe99fc82cc8c35a8c2c2b2ad98
mtn: warning: missing directory 'certification'
mtn: warning: missing directory 'certification/include'
mtn: warning: missing directory 'certification/include/css'
mtn: warning: missing directory 'certification/include/js'
mtn: warning: missing directory 'certification/include/php'
mtn: warning: missing directory 'certification/templates'
mtn: warning: missing directory 'certification/templates/assessor'
mtn: warning: missing directory 'certification/templates/moderator'
mtn: warning: missing directory 'certification/templates/share'
mtn: warning: missing file 'certification/assessor.php'
mtn: warning: missing file 'certification/contact.php'
mtn: warning: missing file 'certification/include/css/certificates.css'
mtn: warning: missing file 'certification/include/css/ie.css'
...


So Monotone is expecting me to figure out which files it is not tracking 
and remove those files before it'll update the working directory? I 
can't have files or directories that monotone does not keep track of? 
The "include/php" directory has an external php library. No sense in 
having that in my monotone database.


Daniel.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Thomas Keller]

Daniel Carrera schrieb:
> Bruce Stephens wrote:
>>> Help?
>>
>> I think disapprove *only* changes the database.  You need to do "mtn
>> update" to change your workspace.
> 
> 
> Ok, I did that. It seems to work, but it also gave me a scary warning.
> For background, the commit that I wanted to remove was the addition of
> several directories with files in them. This is what mtn said:
> 
> % mtn update
> mtn: updating along branch 'org.theingots'
> mtn: selected update target d02074eb70d2bdfe99fc82cc8c35a8c2c2b2ad98
> mtn: [left]  9198ce86d4f514bcf9cc613d170befd65a0ed7b4
> mtn: [right] d02074eb70d2bdfe99fc82cc8c35a8c2c2b2ad98
> mtn: warning: cannot drop non-empty directory 'certification'
> mtn: warning: cannot drop non-empty directory 'certification/include'
> mtn: warning: cannot drop non-empty directory 'certification/include/php'
> mtn: warning: cannot drop non-empty directory
> 'certification/templates/moderator'
> mtn: misuse: 4 workspace conflicts
> 
> 
> I don't like the sound of that. Especially the "misuse" line. I can
> verify with darcs that Monotone didn't break anything. But why did
> monotone say that I'm misusing it and that I have conflicts?

This is something we hopefully remove in the next release. Just move the
certification/ directory out of the way so monotone can cleanly update
your workspace to the previous revision.

Thomas.

-- 
GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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




signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Bruce Stephens wrote:

Help?


I think disapprove *only* changes the database.  You need to do "mtn
update" to change your workspace.



Ok, I did that. It seems to work, but it also gave me a scary warning. 
For background, the commit that I wanted to remove was the addition of 
several directories with files in them. This is what mtn said:


% mtn update
mtn: updating along branch 'org.theingots'
mtn: selected update target d02074eb70d2bdfe99fc82cc8c35a8c2c2b2ad98
mtn: [left]  9198ce86d4f514bcf9cc613d170befd65a0ed7b4
mtn: [right] d02074eb70d2bdfe99fc82cc8c35a8c2c2b2ad98
mtn: warning: cannot drop non-empty directory 'certification'
mtn: warning: cannot drop non-empty directory 'certification/include'
mtn: warning: cannot drop non-empty directory 'certification/include/php'
mtn: warning: cannot drop non-empty directory 
'certification/templates/moderator'

mtn: misuse: 4 workspace conflicts


I don't like the sound of that. Especially the "misuse" line. I can 
verify with darcs that Monotone didn't break anything. But why did 
monotone say that I'm misusing it and that I have conflicts?



Daniel.




___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Undo a commit

[Daniel Carrera]

Lapo Luchini wrote:

Alex Sandro Queiroz e Silva wrote:

It looks like the closest thing, except that it keeps a
history off the change and the undoing of the change. Is that right? Is
that a feature?


Yup, it's because it's "monotonic" in nature you can only add, never remove.



Does that have anything to do with why Monotone is called Monotone?


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel