On Thu, May 11, 2017 at 12:17:44PM +0300, Ron Aaron wrote:
> Sorry, but I can't see how the terminology "... all files if no file
> name is provided" could mean anything but what I assumed.
>
> It may not be used often, but in the event were one has decided, as I
> did, that a certain number of trunk changes (as in: the last 7) need to
> be reverted, it is what one would expect to be able to use. That is,
> "revert not just one file, but all files, to a given revision".
>
> Yes, I can "upd XXX" to get back to XXX. But since I want the continued
> development to be from there on, but I don't want to branch, I have two
> options if 'revert' doesn't work:
>
> 1. Do "merge --backout" in reverse order for each of the N revisions I
> want to remove, or
> 2. Do "upd XXX" and then "ci --allow-fork", than "upd trunk" and "merge
> that-branch" and then close that-branch
>
> Neither is nearly as simple and intuitive as "revert".
>
> No, I didn't want to update to that revision, I wanted to replace the
> tip with that revision.
In that case, it mean that all changes following XXX needs to become a
new branch that would will abandon or continue development later. This
happens often to me, here what I do normally:
1. fossil co --force XXX
(or "fossil up XXX" if you want to keep uncommited changes)
2. Edit the checkin following XXX (using fossil ui) and use "make
this checkin the start of a new branch:", This way XXX will
become the new tip of trunk.
I found this better than having revert to do what you want, because here
we know what's happens by looking the timeline.
If the commits following XXX was really a mistake, you can just name
this branch "mistake" and you can optionally hide it.
Regards,
--
Martin G.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
