On Fri, 11 Jan 2013 13:06:17 +0100 Gilles <gilles.gana...@free.fr> wrote:
>> Am I correct in understanding that this is the right way to proceed >> to try some new code, and either save it (whether it works or not, >> just as a track-record) or discard it? > > So the right way to experiment and keep tried code for later reference > is to save those trials in a branch, distinct from the trunk. > > But since I've never used branching, I'm not clear about how to see > which files have been saved in the branch vs. those in the trunk, You don't need this: a branch diverges from the trunk (in your case), rather than appearing out of the void, so initially it has the same files in the same state the trunk does. Moreover, the Fossil's philosophy is that a new branch is only created when the first commit on it is made, so you start with the trunk, do some changes then do fossil commit --branch crazy_idea and only then your new branch comes into existence. Getting the diff between the starting point of the branch (or an earlier state) is quite rarely needed -- most of the time you're interested in the diff between your work directory (local changes) and its base version (the last recorded commit on the current branch). If you still need the diff between two arbitrary commits, use fossil diff --from A --to B where A and B are either branch/tag names or (possibly abbreviated) hashes of the relevan commits, extracted from the timeline view. You can omit either --from or --to, so, to diff your current checkout to the trunk, just use fossil diff --from trunk > and how to check the changes made in a branch to such and such file, Fire up Fossil web UI and click on the links marked "patch" and "diff" in the commit view. > and how to go back and forth between the trunk and the branch before > applying "commit". Technically, just by doing `fossil update <branchname>` as this tries to merge your uncommitted local changes with the <branchname> you're switching your open checkout to. But, again, what you're asking for is not needed as this is not how VCSes work, so don't do that. Instead, implement your feature on your branch, and if you're OK with it and want it in your mainline (the trunk), go back to the trunk and then *merge* your feature branch into it -- this will bring all the changes implemented on that feature branch and will record that your new commit has two parents (the trunk and the feature branch) so you have understanable history record. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
