On Fri, Nov 16, 2012 at 5:12 AM, Gilles <[email protected]> wrote:
> Hello
>
> This is a newbie question.
>
> Prior to using Fossil, to try something and still be able to go back
> in case the change didn't work, the only way I had was to comment
> things out.
>
> Now that I'm used to using Fossil, I just keep a DOS box open so I can
> easily run "fossil.exe commit -m "Some comment"" before making
> changes.
>
There are many ways to do this. I will present one way. Others might give
you other ideas, each with various advantages and disadvantages.
I propose that you put your experimental changes on a branch:
fossil commit -m "Some comment" --branch experimental
You can use whatever branch name you want. It does not need to be
"experimental". And once you do a single check-in to a branch, you are
"on" that branch and can omit the --branch option on subsequent check-ins.
After several check-ins if you do not like one things are working out, just
do:
fossil update trunk
And that will take you back to the point of your first check-in to the
branch. (If you have uncommitted changes, you should do "fossil revert"
first.)
If you do like your changes and want to fold them into trunk, then do:
fossil update trunk
fossil merge experimental
(Again, it is best to ensure that you do not have uncommitted changes when
you do this.) The above will first take you back to the trunk, then pull
in all the changes you made in the "experimental" branch into your
checkout. Do one last check to make sure that these changes are as you
want then, then do:
fossil commit
Yes, this is an exceedingly newbie question. But if you have never worked
with a software configuration management (SCM) system and especially with a
distributed SCM (DSCM) like Fossil, then the work-flow is probably pretty
mysterious to you. More experienced hands (read: most others reading this
list and especially those with check-in privileges to Fossil) need to
figure out some way of better explaining how Fossil (and other DSCMs) work
to people who have never seen the concepts before. This is very hard for
us since the core concepts of DSCM are like second nature - it is like
trying to explain how to walk - we can't explain it; we just do it without
thinking.
> However, in case the change didn't work, what is the best/easiest way
> to tell Fossil to forget about it and go back to the last commited
> version? Is "fossil.exe revert "myfile.txt"" OK?
>
> What about if changes involve multiple files? Will "fossil.exe revert"
> forget all the changes made to all the files, and fetch the latest
> commited versions from the repo so I can try something else?
>
> Thank you.
>
> _______________________________________________
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
D. Richard Hipp
[email protected]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
