On Thu, 2012-03-29 at 19:40 +0200, mlfconv wrote: > Hi Ron, > > thanks for your advice, will try, right now I'm unable to figure out > how to switch to a branch or commit into a branch - it seems that if I > run: > > fossil branch new B > fossil add somefile.c > fossil commit -m"commit" --branch B > > the graph indicator creates 3 separate arrows instead of 2 and it > looks as if fossil thinks that I'd like to have 2 distinctive branches > both called B. > > Also creating another branch C actually creates one but when commiting > another somefile.c, the arrow pointing from somefile.c tagged 'B' > would point to somefile.c tagged'C' however another arrow would point > from trunk to branch 'C' but not from branch'C' to somefile.c tagged > 'C'. All I'm running are the above mentioned cmds repeatedly and in > that order. > > thanks, > > Marek >
To expand a bit on Stephen Beal's answer (because there are lots of different ways to use fossil): I think of fossil checkout (co) as "get me a copy of the contents of the repo right here, absolutely and without regard to what I happen to be doing." I tend to use fossil update for almost everything as it seems to be to be more forgiving of my sloppy work habits: tif@whiskey-five:~/Desktop/Projects/ACSS/project$ fossil help update Usage: fossil update ?VERSION? ?FILES...? Change the version of the current checkout to VERSION. Any uncommitted changes are retained and applied to the new checkout. <snip> The -n or --nochange option causes this command to do a "dry run". It prints out what would have happened but does not actually make any changes to the current checkout or the repository. So if I've changed something but realize it belongs in a different branch than I happen to have open fossil update lets me change branches and brings the new changes with it. If my spidey sense starts tingling I'll do a "fossil update <branch_name> -n" to make sure no funny business is about to happen. So I only ever use fossil checkout immediately after making a new working directory and doing a fossil open. I had it (fossil co) overwrite a couple of files early on in my learning curve and I've been gunshy about using it on a working repo since. To get what you are looking for above you can do it several ways: fossil branch new B fossil update B fossil add somefile.c fossil commit -m "commit" or, more simply: fossil add somefile.c fossil commit -m "commit" --branch B Which is how I tend to work. In either case fossil status will show your working directory is now tracking branch B. The breakdown of the commands you gave (assuming you started in trunk) is as follows: > fossil branch new B -- just create a branch named B > fossil add somefile.c -- add somefile.c to the repo in the currently checked-out branch (assuming trunk) > > fossil commit -m"commit" --branch B -- commit changes to a new branch named B Just a few words that will hopefully help you on your way. Also -- a bit of unsolicited advice that I wish I had not had to learn the hard way: Early on I thought it might be a good idea to structure my projects like so: project |_ project.fossil |_ file1 |_ dir1 |_ etc It's not. Keep your working repo (assuming you're starting with a single machine - single repo setup like I did) out of your project directory. You'll quickly find that you rely on fossil to keep things for you and that it does a fantastic job, and you may start playing fast and loose with the command link because, after all, no matter what you do your files are safe. There's quite a lot of power in being able to act this way towards a project, but with the repo in the project directory as above you're always one ill advised wildcard on an rm command away from losing everything :) Themba > > > -------- Original Message -------- > From：Ron Wilson <ronw.m...@gmail.com> > Time：3/28/2012 19:12 > To：Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> > Subject：Re: [fossil-users] import of ancient projects > > > On Wed, Mar 28, 2012 at 12:54 PM, mlfconv <mlf.c...@gmail.com> wrote: > > basically i don't want Fossil to perform a merge of A2 and B2 (A is > the > > master branch) but insert another file which only acts as a merge > and is > > tagged or labeled as merge but no actual merge is performed by > Fossil, A3 is > > only inserted instead of merging (A3 actually is a file that merged > two > > distinct features from A2 and B2 which is why I want to keep it as > > historical record instead of doing an actual merge, also B2 evolved > into B3 > > after "merge" into A3. > > As long as you don't mind that the revision graph will not show any > indication of a merge, you can just commit A3 as is. > > If you do want the graph to show a merge, you can do a fossil merge, > then replace the result with your A3 before commiting. > > (As I mentioned, fossil merge does not automatically commit the result > of a merge. In your case, it would merge changes from B into your > working copy of A2, leaving the resulting files for you to > review/edit/replace, then you have to do the actual commit.) > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
