Re: [fossil-users] how to branch
Thus said Konstantin Khomoutov on Tue, 14 May 2013 07:40:41 +0400: > That is, it's backwards: you first do some work, then decide to commit > and decide this commit should start its own branch rather than > continuing the current one, so you create that new branch while > committing. Not exactly backwards, but more of a convenience. If you suddenly discover that your changes should not yet go into the trunk, you can branch at the moment of the commit. This makes branching extremely easy to accomplish and less of a hassle to get the changes committed without breaking the rest of the sources. With other VCS you would have to go through a few more girations to get your newly changed files committed at the *right* location. However, it is also just as easy to pick a particular node in the DAG and branch from that too which is what the fossil branch command allows for. Andy -- TAI64 timestamp: 40005191cef9 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to branch
On Tue, May 14, 2013 at 01:55:56AM +, varro wrote: > I've been experimenting with fossil for some private projects of mine > and now want to use the 'branch' facility. According to the 'help' > text for 'branch', the syntax to create a new branch is: > > fossil branch new BRANCH-NAME BASIS ?OPTIONS? > > but it doesn't explain what BASIS is. > > Looking at the Jim Schimpf book, I see he gives as an example: > > fossil branch new VER_1.0 trunk -bgcolor 0xFFC0FF > > Trying this on one of my own repositories, I tried: > > % ls -l recepsum.fossil > -rw-r--r-- 1 william william 129024 Apr 30 21:17 recepsum.fossil > > % fossil branch new UI trunk -R recepsum.fossil > fossil: use --repository or -R to specify the repository database > > Excuse me if I've missed something obvious here, but I've been staring > at this and don't see what I'm doing wrong. You seem to confuse branching with checking out a branch (to a working directory). You first need to "open" your repository: % mkdir recepsum; cd $_ % fossil open ../recepsum.fossil (So now you have your working directory initialized and linked to that repository, which you can verify by running `fossil status`.) And now you can do branching at will using `fossil branch`. Note though that while Fossil does allow you to create a branch before starting to work on it, it's "standard" mode of operation (as envisioned by its creator) is to use the "--branch" command-line option when recording the first commit on the branch which is about to be created. That is, it's backwards: you first do some work, then decide to commit and decide this commit should start its own branch rather than continuing the current one, so you create that new branch while committing. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] how to branch
Hi, I've been experimenting with fossil for some private projects of mine and now want to use the 'branch' facility. According to the 'help' text for 'branch', the syntax to create a new branch is: fossil branch new BRANCH-NAME BASIS ?OPTIONS? but it doesn't explain what BASIS is. Looking at the Jim Schimpf book, I see he gives as an example: fossil branch new VER_1.0 trunk -bgcolor 0xFFC0FF Trying this on one of my own repositories, I tried: % ls -l recepsum.fossil -rw-r--r-- 1 william william 129024 Apr 30 21:17 recepsum.fossil % fossil branch new UI trunk -R recepsum.fossil fossil: use --repository or -R to specify the repository database Excuse me if I've missed something obvious here, but I've been staring at this and don't see what I'm doing wrong. -- Will ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
Richard Hipp wrote: On Mon, May 13, 2013 at 4:43 PM, Andy Bradford mailto:amb-fos...@bradfords.org>> wrote: Thus said Miles Fidelman on Mon, 13 May 2013 16:09:30 -0400: > I also wonder if it effected the choice of whether to use fossil or > not for various projects. I know that, personally, there are a few > places that I've wanted to START with versioned documentation, and > would have jumped on Fossil in an instant if the pieces where there. One can always version control the documents in a separate directory called docs. ;-) Of course it won't be served up via Wiki, Sure it can. See http://www.fossil-scm.org/fossil/doc/trunk/www/embeddeddoc.wiki for a description. Every page of the Fossil website (http://www.fossil-scm.org/) except for the precompile-binary download page, is done exactly this way. The document source files (usually Fossil Wiki, but HTML, plaintext, and Markdown can also be used) are part of the source tree and are checked in and checked out and edited just like C-code. The only thing you can't do is edit the content on-line. In order to edit the content, you have to have a clone of the repo, do a check-out, edit on your disk, the commit. This can be seen as either a feature or a bug, depending on your point of view. Yes, but for collaborative document writing, something more like a full wiki, is just that much nicer. So close, but... Can't have everything, I guess. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
On Mon, May 13, 2013 at 6:47 PM, Andy Bradford < amb-sendok-1371077232.ipnkckchbfagchdof...@bradfords.org> wrote: > Is > customization of the menu in the web UI possible? > Of course. Visit Admin->Header to edit the TH1 script that generates the header. It isn't hard. You can modify the CSS and footer in the same way. Over at Admin->Configuration you can decide which page to make the "default" page. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
Thus said Richard Hipp on Mon, 13 May 2013 16:57:08 -0400: > On Mon, May 13, 2013 at 4:43 PM, Andy Bradford wrot e: > > > One can always version control the documents in a separate directory > > called docs. ;-) Of course it won't be served up via Wiki, > > Sure it can. See > http://www.fossil-scm.org/fossil/doc/trunk/www/embeddeddoc.wiki for a > description. Nifty! Ok, I was unaware of this ability. This certainly might lessen the need to have version control on the Wiki. > FWIW, the documents for Fossil itself are contained in the "www" > directory, not the "docs" directory. But that is just project-specific > convention. You can put them anywhere you want on your project. This is definitely an improvement over just the Wiki. I notice that www.fossil-scm.org has a Home and Documentation menu item that goes to these ``embedded documentation'' /doc URIs. Is customization of the menu in the web UI possible? Or is it better just to have the main Wiki page link to the ``embedded documentation'' for the project? If the latter, it seems like we're back to square one: how does one go about correcting forks in the Wiki edits? I found this page, and it's helpful in understanding the Wiki, but basically reiterates what has already been said (e.g. there are no tools): http://www.fossil-scm.org/xfer/doc/trunk/www/wikitheory.wiki Thanks, Andy -- TAI64 timestamp: 400051916d90 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
On Mon, May 13, 2013 at 4:43 PM, Andy Bradford wrote: > Thus said Miles Fidelman on Mon, 13 May 2013 16:09:30 -0400: > > > I also wonder if it effected the choice of whether to use fossil or > > not for various projects. I know that, personally, there are a few > > places that I've wanted to START with versioned documentation, and > > would have jumped on Fossil in an instant if the pieces where there. > > One can always version control the documents in a separate directory > called docs. ;-) Of course it won't be served up via Wiki, Sure it can. See http://www.fossil-scm.org/fossil/doc/trunk/www/embeddeddoc.wiki for a description. Every page of the Fossil website (http://www.fossil-scm.org/) except for the precompile-binary download page, is done exactly this way. The document source files (usually Fossil Wiki, but HTML, plaintext, and Markdown can also be used) are part of the source tree and are checked in and checked out and edited just like C-code. The only thing you can't do is edit the content on-line. In order to edit the content, you have to have a clone of the repo, do a check-out, edit on your disk, the commit. This can be seen as either a feature or a bug, depending on your point of view. FWIW, the documents for Fossil itself are contained in the "www" directory, not the "docs" directory. But that is just project-specific convention. You can put them anywhere you want on your project. > but maybe it > could be automated (e.g. after checkin, do a recursive commit of all the > files in the docs directory with fossil wiki commit or something). > > One of the things that did attract me to Fossil was the ability to link > or associate specific commits for fixes to tickets and have it all show > up nicely in the timeline. > > Andy > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
Thus said Miles Fidelman on Mon, 13 May 2013 16:09:30 -0400: > I also wonder if it effected the choice of whether to use fossil or > not for various projects. I know that, personally, there are a few > places that I've wanted to START with versioned documentation, and > would have jumped on Fossil in an instant if the pieces where there. One can always version control the documents in a separate directory called docs. ;-) Of course it won't be served up via Wiki, but maybe it could be automated (e.g. after checkin, do a recursive commit of all the files in the docs directory with fossil wiki commit or something). One of the things that did attract me to Fossil was the ability to link or associate specific commits for fixes to tickets and have it all show up nicely in the timeline. Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
Lluís Batlle i Rossell wrote: On Mon, May 13, 2013 at 10:58:04AM -0400, Richard Hipp wrote: On Mon, May 13, 2013 at 10:41 AM, Andy Bradford wrote: When I first learned about fossil and the integrated tickets/wiki, I assumed that both of these features were also version controlled just like any other might that might exist in the repository. The Wiki is version controlled with a DAG, just like code. But it is a separate and independent DAG. And the current user interface does not give you access to the details of the change history. That UI could be enhanced to do that, if there is a need, but in 6 years nobody has complained and so it has not yet happened. And now that there have been complains? :) Does anyone want to endeavour the task? I've the feeling that the question had come up before, but simply noone developed a solution. I also wonder if it effected the choice of whether to use fossil or not for various projects. I know that, personally, there are a few places that I've wanted to START with versioned documentation, and would have jumped on Fossil in an instant if the pieces where there. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
On Mon, May 13, 2013 at 5:10 PM, Lluís Batlle i Rossell wrote: > I've the feeling that the question had come up before, but simply noone > developed a solution. > The topic has come up once or twice before, but the threads have been short and i don't think anyone ever actually voiced it in the form of a feature request ;). Another approach is to say, next year, "in 7 years nobody has complained". > ;) > +1 ;) (But that's only to say that i can't personally commit to implementing it! i'm all for it someone else wants to, though. It would be a nice addition.) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
On Mon, May 13, 2013 at 10:58:04AM -0400, Richard Hipp wrote: > On Mon, May 13, 2013 at 10:41 AM, Andy Bradford > wrote: > > > > > When I first learned about fossil and the integrated tickets/wiki, I > > assumed that both of these features were also version controlled just > > like any other might that might exist in the repository. > > > The Wiki is version controlled with a DAG, just like code. But it is a > separate and independent DAG. And the current user interface does not give > you access to the details of the change history. That UI could be enhanced > to do that, if there is a need, but in 6 years nobody has complained and so > it has not yet happened. And now that there have been complains? :) Does anyone want to endeavour the task? I've the feeling that the question had come up before, but simply noone developed a solution. Another approach is to say, next year, "in 7 years nobody has complained". ;) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
On Mon, May 13, 2013 at 10:41 AM, Andy Bradford wrote: > > When I first learned about fossil and the integrated tickets/wiki, I > assumed that both of these features were also version controlled just > like any other might that might exist in the repository. The Wiki is version controlled with a DAG, just like code. But it is a separate and independent DAG. And the current user interface does not give you access to the details of the change history. That UI could be enhanced to do that, if there is a need, but in 6 years nobody has complained and so it has not yet happened. > Why should they > not be? And why should they not be just as simply accessible (e.g. > source controlled) as any other file that I might place in a repository? > > Thanks, > > Andy > -- > TAI64 timestamp: 40005190fbcc > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
Thus said Stephan Beal on Mon, 13 May 2013 11:04:23 +0200: > While i'm not at all against the idea of upgrading the wiki pages to > full-fledged content, i just want to point out that this feature > would affect more than the www GUI: the (fossil wiki commit) and > (/json/wiki/save) commands would also be affected by this, and would > need to be expanded to catch/reject/report merge conflicts. I'm new to fossil so this approach may not work, but cannot these interfaces always just do a forced commit which may or may not cause a fork (perhaps reporting in some fashion for clients that might care)? Then couldn't the fossil command line tool be used to merge and resolve any conflicts? When I first learned about fossil and the integrated tickets/wiki, I assumed that both of these features were also version controlled just like any other might that might exist in the repository. Why should they not be? And why should they not be just as simply accessible (e.g. source controlled) as any other file that I might place in a repository? Thanks, Andy -- TAI64 timestamp: 40005190fbcc ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
On Mon, May 13, 2013 at 11:04:23AM +0200, Stephan Beal wrote: > On Mon, May 13, 2013 at 10:55 AM, Lluís Batlle i Rossell > wrote: > > > A simple operation (similar to edit, just with the merge conflicts) could > > allow > > merging multiple leaves. > > > > What do you think? > > > While i'm not at all against the idea of upgrading the wiki pages to > full-fledged content, i just want to point out that this feature would > affect more than the www GUI: the (fossil wiki commit) and > (/json/wiki/save) commands would also be affected by this, and would need > to be expanded to catch/reject/report merge conflicts. That would be > relatively easy for (wiki commit), where we can simply exit() on conflict, > but more work for /json/wiki/save, where the conflict has to be reported > back to the user along with the conflict-merged data. Such a "non-success" > case does not fit in with the current "100% success" _or_ "100% failure" > response model, and the error reporting mechanism does not allow one to > send a payload back to the client (in this case the conflicted content). So > i'd need to find a mechanism we could use to report such > "not-total-failures" which isn't too difficult for clients to work with. No, I only mean that the wiki pages should report about *multiple leaves*. With the current artifacts, wiki pages include the 'Parent artifact id', so it should be already possible to report that. I don't mean that we block any user in any operation. Then, we only need an extra operation that could *merge*. Imagine that you click the "Merge leaves" link; it should offer a text input like with wiki edit, but with the conflicts inside. The artifact of the wiki page, then, could include multiple parent artifact id to mean a merge. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
On Mon, May 13, 2013 at 10:55 AM, Lluís Batlle i Rossell wrote: > A simple operation (similar to edit, just with the merge conflicts) could > allow > merging multiple leaves. > > What do you think? While i'm not at all against the idea of upgrading the wiki pages to full-fledged content, i just want to point out that this feature would affect more than the www GUI: the (fossil wiki commit) and (/json/wiki/save) commands would also be affected by this, and would need to be expanded to catch/reject/report merge conflicts. That would be relatively easy for (wiki commit), where we can simply exit() on conflict, but more work for /json/wiki/save, where the conflict has to be reported back to the user along with the conflict-merged data. Such a "non-success" case does not fit in with the current "100% success" _or_ "100% failure" response model, and the error reporting mechanism does not allow one to send a payload back to the client (in this case the conflicted content). So i'd need to find a mechanism we could use to report such "not-total-failures" which isn't too difficult for clients to work with. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki-Pages synchronisation
On Wed, May 08, 2013 at 07:28:59AM -0400, Richard Hipp wrote: > On Wed, May 8, 2013 at 6:56 AM, Lluís Batlle i Rossell > wrote: > > > I don't see why most VCS tend (somehow propose) to *not commit* merge > > conflicts before solving the conflicts. That makes the conflict solution > > 'disappear' from the timeline. > > > > One reason: Having non-working code in the tree makes doing a bisect very > difficult. In that case, maybe it'd be nice to keep some kind of commit tree also for wiki pages; a gui should be able to show the multiple leaves, if they happen. Nowadays, what would be 'multiple leaves' go unnoticed. A simple operation (similar to edit, just with the merge conflicts) could allow merging multiple leaves. What do you think? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
