Re: [Monotone-devel] Re: Undo a commit
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
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
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
[Monotone-devel] Re: Undo a commit
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. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Selon 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). I don't see why; the altered _MTN/revision still contains the new manifest ID that has the new, moved or deleted files. Or am I missing something? -- 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 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 rev $ 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
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
[Monotone-devel] Re: Undo a commit
Selon Daniel Carrera: Ludovic Brenta wrote: 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. I would prefer a single-purpose command, mtn rebase -r rev, 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. -- 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
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
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 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 rev, 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 rev 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
[Monotone-devel] Re: Undo a commit
Selon Daniel Carrera [EMAIL PROTECTED]: 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? Yes, that's right. Now, how do I edit _MTN/revisions? It appears to contain 2-3 hashes: [...] 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? Change the old_revision and leave the others alone. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Daniel Atallah [EMAIL PROTECTED] writes: [...] 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. The same's true (well, sort of) for git, mercurial, darcs. The understanding is that if you mess with history in this way you'd better understand the consequences. In practice that still leaves the operations frequently useful. It's common while testing out a change (before pushing it anywhere) to want to fix it. (When using CVS I quite often used quilt for that purpose, as a short-term local VCS.) Linus didn't just want to be able to merge changes quickly, he wanted to be able to reject changes and for it to be practical for the submitters to beat the changes into an acceptable state. So git has features for doing that, allowing users to rewrite history (while keeping the old versions around for a period, to avoid losing things). monotone lacks similar features, but I'm not sure anybody would object to them being added. It just hasn't happened. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Ludovic Brenta [EMAIL PROTECTED] writes: [...] I would prefer a single-purpose command, mtn rebase -r rev, 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. 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).) ___ 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 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
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 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
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
Bruce Stephens wrote: Ludovic Brenta [EMAIL PROTECTED] writes: I would prefer a single-purpose command, mtn rebase -r rev, 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 writes: mtn rebase rev 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
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
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
[Monotone-devel] Re: Undo a commit
Daniel Carrera [EMAIL PROTECTED] writes: 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. Erm, kind of. I think it does what you want, though. [...] ___ 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 [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
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
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
[Monotone-devel] Re: Undo a commit
Daniel Carrera [EMAIL PROTECTED] writes: How do I undo a commit? I just made a commit and I just realized that the commit included a file that I did not want committed in this patch. What's the command to undo the last commit call? Is disapprove the right command? 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? Correct, and it's a feature. You might alternatively commit the corrected revision (to the parent), and add a suspend cert to the wrong one. That still leaves the change there, but it'll generally be ignored. You can also kill a revision in your local database (using db kill_revision_locally). (So there's no easy equivalent to amend-record, to amend a commit (with the proviso that the user is responsible for the mess if the commit has been propagated somewhere). I don't know that there's any strong reason for that---I think it's just that nobody's written one.) [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
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. If the change has not been propagated yet, you can use 'mtn db kill_rev_locally'. Or also if it was sync'ed to few places and you can manade to kill_rev on each AND EVERY ONE. (else with any subsequent sync the revision will keep returning back) -- Lapo Luchini - http://lapo.it/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
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
[Monotone-devel] Re: Undo a commit
Daniel Carrera [EMAIL PROTECTED] writes: 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? No, not really. The original idea (IIRC) was that monotone update would always give you a tree that was no worse than the one you had before. So you'd have a tree that was monotonically improving in some useful sense (or at least non-decreasing in quality). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Bruce Stephens wrote: 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? No, not really. The original idea (IIRC) was that monotone update would always give you a tree that was no worse than the one you had before. So you'd have a tree that was monotonically improving in some useful sense (or at least non-decreasing in quality). Uh, really? 0_o I had thought for the past years that monotone meant just that… -- Lapo Luchini - http://lapo.it/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Lapo Luchini [EMAIL PROTECTED] writes: Bruce Stephens wrote: 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? No, not really. The original idea (IIRC) was that monotone update would always give you a tree that was no worse than the one you had before. So you'd have a tree that was monotonically improving in some useful sense (or at least non-decreasing in quality). Uh, really? 0_o I had thought for the past years that monotone meant just that… Yes, I think it was about monotonically non-decreasing quality, not about never removing stuff. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Daniel Carrera [EMAIL PROTECTED] writes: [...] So I am still at the a4042.. revision. And in the log I can see that it mentions the file that I did not want to include in this commit. Help? I think disapprove *only* changes the database. You need to do mtn update to change your workspace. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
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 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
[Monotone-devel] Re: Undo a commit
Daniel Carrera wrote: 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 Should essentially mean: this update should delete directory 'certification' (and childs) but they also happen contain some extra non-versioned files I'm not allowed to delete, so you must take care of 'em beforehand. PS: yep, monotone's error messages are more often than not a bit conservative and/or excessive (there still quite a few use-cases when it spits out monotone fatal error, probably caused by a bug when the actual error would be something else such as you probably mis-configured your charset/language or something) Problem with those is that power-users tend to forget about 'em and have little motivation to improve 'em, I fear ;-) -- Lapo Luchini - http://lapo.it/ “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone.” (Kansas State Legislature) ___ 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 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
[Monotone-devel] Re: Undo a commit
Daniel Carrera [EMAIL PROTECTED] 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. I can't have files or directories that monotone does not keep track of? Of course. monotone is just refusing to remove them. The include/php directory has an external php library. No sense in having that in my monotone database. True. On the other hand, how is monotone to know that it's OK to delete that? In this case I guess a good way to do it would be to remove (or move away) certification/, then do mtn revert certification to restore the files that monotone thinks should be there, then do mtn update. (GNU Arch had (presumably still has) a more subtle distinction between tracked files, junk files (that can be freely deleted), precious files (that are expensive to generate), and maybe other kinds (I forget). With that kind of configuration a VCS might be able to do the right thing, but I don't think that aspect of GNU Arch was very popular.) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
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 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
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
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 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 [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 [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 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
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
[Monotone-devel] Re: Undo a commit
Daniel Carrera 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'. 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. -- Lapo Luchini - http://lapo.it/ “Random numbers should not be generated with a method chosen at random.” (Donald Knuth, Seminumerical Algorthms) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Undo a commit
Ludovic Brenta wrote: 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. No longer needed to revert first: db kill_rev_locally is now smart enough to move the workspace in the previous state, complete with (uncommitted) changes you had before the commit itself. -- Lapo Luchini - http://lapo.it/ “The sky above the port was the color of television, tuned to a dead channel.” (William Gibson, Neuromancer) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
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
[Monotone-devel] Re: Undo a commit
Daniel Carrera wrote: So I don't blame mtn update for changing the files. I think that the problem is with mtn disapprove But actually disapprove is not meant to be an un-commit, it is meant to mean hey, that patch that some guy landed in the main branch is *BAD*, it breaks thing, I don't want it, I want to back that out. In this context, I think what it does is what should be done... OTOH I never ever used disapprove myself so, not having real use-cases at hand, my opinion count less than yours ;-) (monotone developement has been historically very use-case-driven) 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. 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) but the database-behaviour of disapprove (a commit that reverts the previous one), is that so? 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. 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 ;-) 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 do agree having to edit _MTN/options manually is not the cleanest solution, but OTOH wanting to revert something big and synchronized elsewhere while at the same time having an old workspace is not a very clean problem by itself, probably... but I guess this is quite the area of patches with improved functionality are very welcome, given they have a decent UI and don't break other uses) -- Lapo Luchini - http://lapo.it/ “Violence is the last refuge of the incompetent.” (Isaac Asimov, Foundation, 1942-05) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Undo a commit
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 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
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
