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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users