4

While using Mercurial if I want to change the current working copy with a specific revision I just do:

$> hg revert good_revision
$> hg commit -m "Now I'm in the good revision"

Then I can see that all my files are int the good_revision state and can start working on it.

So far on fossil I can do a revert but only on specific files, not the entire repository, and update or checkout don't seem to work as I would expect.

How can fossil revert my entire repository to a certain revision?

Timoteo Ponce
  • 510
  • 9
  • 27
  • BTW, `hg revert` is **wrong** solution for your task "update to specific revision" – Lazy Badger Jul 08 '14 at 06:56
  • I didn't mention 'update to specific revision', I mentioned it as 'change to a specific revision', perhaps I have mistaken the 'change' word, it might have been better to use 'revert'. – Timoteo Ponce Jul 08 '14 at 12:16
  • If you just want to revert a single revision you can use fossil merge --backout – Breezer Nov 19 '15 at 11:29

3 Answers3

7

I'm not sure I quite follow but I think what you want is to be able to create a "multiple heads on one branch" sutuation in Fossil. If yes, then Fossil does support this, just it calls branch's heads "leaves", and this process is called "forking".

To do that, you

fossil update good_revision

and then

fossil commit --allow-fork

You may now spawn fossil ui, navigate to your branch and see it having two leaves.

You now may close the then-current leaf.

Note that, while supported, this does not appear to be a recommended practice. Instead, Fossil recommends a rather peculiar approach for throwing away changes:

  1. Rename the branch at the "bad" leaf to "mistake" (or create that branch if it doesn't yet exist). By doing this you effectively "mark" the resulting subleaf as a mistake.

    Note that the name "mistake" name is just a convention; this branch does not exist in a freshly created repository.

  2. Close the "bad" leaf.

  3. Return to the last-good state using fossil update, continue hacking.

    Since that "last-good" commit still inherits the branch tag of its parent commit, the next commit you record will also inherit it and won't be on the branch "mistake".

For an example, see how it looks in the SQLite repo—there's a bunch of assorted short chains of commits on this branch. See also this.

kostix
  • 51,517
  • 14
  • 93
  • 176
  • Almost there, what is missing is that I want that new leaf (the one created with --allow-fork) becomes my new trunk. – Timoteo Ponce Jul 07 '14 at 17:49
  • @TimoteoPonce, Ugh, I think you might be misunderstanding Fossil's branching model. It supports several leaves *per branch* so you cannot have a leaf which is *the* trunk because all leaves on the branch named "trunk" have the same "rank". – kostix Jul 07 '14 at 21:24
  • @TimoteoPonce, on the other hand, if you have just a single open leaf (and any number of closed, including none) on a branch you might consider that leaf to be *the* branch. But I'd not delude myself anyway. Hence my answer indeed deals with this issue. – kostix Jul 07 '14 at 21:28
  • Indeed it does, I just applied that and it worked as expected, thank you sir. – Timoteo Ponce Jul 07 '14 at 21:41
2

My slightly different solution to what I think I understand the question to be (paraphrased: how to work on an older "good_revision" than current leaf of this branch/trunk that I'll call bad_leaf, and treat changes since "good_revision" as bad), which is sort of equivalent to applying diffs between the two versions but in reverse from/to order:

Merge in a (empty) fork from the good_revision, using the baseline from the bad_leaf instead of the default, last common commit; hence the diffs that will be applied are the original branch's differences back to a good_revision fork you create as it won't see they've already been applied. Using the latest as baseline "hides" those which would otherwise make it ignore all changes as they're already applied.

fossil update good_revision
fossil commit --allow-fork --allow-empty
# note the uuid from that commit (for use as forked_basis below)
fossil merge -f --integrate --baseline bad_leaf forked_basis

Then of course once happy,

fossil commit

It doesn't create any branches that should be called "mistake", it just applies the reverse diffs from good_revision to bad_leaf into bad_leaf to put you back where you were and you can continue committing to that same (new) leaf that used to be at bad_leaf.

A diff (straight gnu, not fossil diff) against a checkout at the original good_revision compared to a checkout after the above commands matched. Except for empty directories that had lost their files, but fossil doesn't track/tidy-up dead directories anyway.

caveat: I haven't been using fossil that long and its different in several ways to the common ways I've been used to with cvs/svn/git/hg/ perforce/clearcase.

Reason for adding this answer: I found the existing answers harder to understand and wasn't sure I trusted myself to do them correctly as a result.

Breezer
  • 483
  • 3
  • 10
  • Note: if the edit you're reverting was just accidentally put on this branch from another that should have this edit, you'll need to apply some care if merging changes back into the other branch so it doesn't revert the change there too. – Breezer Nov 24 '15 at 10:40
2

If I understand your question correctly, there was a problem somewhere along the development cycle and you would now like to go back one or more revisions to a known good revision and start using that. Furthermore, you'd like that revision to become your trunk. The approach in Fossil is similar to that of Mercurial:

fossil revert -r good_revision
fossil commit -m "Now I'm in the good revision"

This will replace the files in the working directory with the ones from the specified revision. The commit will commit them to whatever branch you're working on (I am assuming that it is the trunk in this example). If you don't specify the revision number, it will use the last committed version.

One of the more common usages of the revert command is to roll back a single file:

fossil revert  -r good_revision  my_file
    (or)
fossil revert  my_file_from_the_last_commit

However, as shown in the first example, leaving out the file name causes all files to be reverted. For further information please see https://www.fossil-scm.org/index.html/help?cmd=revert

Sorry for the latest response, but I just came across the question while looking for something else. I post this in case someone else is looking into how to revert to a previously committed version stored in Fossil.

staticProblem
  • 159
  • 1
  • 3