Re: [fossil-users] applied DVCS for collaborative work - on the fossil project itself, or otherwise
One partial solution available today is to use http://chiselapp.com. Simply use their clone repo feature with regular pull. What is missing is a way to register the fork with the original project. It would be cool if it was possible to submit the URL of the forked repo to the parent. The parent can verify that the URL is a real fork and not some random URL and then make the forks (with description?) browseable on a Forks page. The final piece of the puzzle would be the mechanism to pull only a single branch from a remote repo. What are the technical challenges with that? Is it enough to query the db for all the nodes on the branch and pull only that data or is there more to it? On Wed, Dec 12, 2012 at 3:27 PM, C. Thomas Stover c...@thomasstover.comwrote: blabbing I have made some great progress on my continuing quest for fire with Fossil yesterday and today. In this episode, my juggling of over-committed time cycled back around to answering questions about branching and merging in the context of various development models using Fossil. In no way am I ashamed to say this this entire area (not just with Fossil) can be exceedingly complex, and really can make an old dog feel incapable of learning new tricks. Chin up, and persevere. For all the playing around with it is very much worth the headaches. The DVCS model(s) really are powerful time amplifying tools, of which Fossil clearly is the least nonsense, most purposeful winner. /blabbing For example, to experiment with some private changes to an actively developed codebase within a publicly cloneable Fossil project, one simply (honoring licenses, etc): 1. clones it 2. makes a branch 3. hacks 4. occasionally --pull from the official project; and merge with trunk 5. optionally publicly host this repository Now for some questions and observations... If the official project maintainers would like to bring in this branch onto their own Fossil server (either to simply host it, or to attempt a merge) they can do so with a --pull. However this currently would have the consequence of the all or nothing (wiki pages, other branches, tickets) behavior. Even so, having Fossil display and generate diffs so as to allow the changes of choice to be visualized and read clearly before being patched into a forked version (official or otherwise) is still about 1000:1 sanity improvement over emailing diff attachments. A project using Fossil may host some code with a F/OSS license of some kind, but it may or may not have as copyright holders granted the right to re-host things like wiki pages. So this detail would need to be considered before hosting a clone of someone else's project. Again some type of clone/push/pull granularity might be useful to avoid a legal, courtesy, or outright malicious incident. Consider the case of a new user who wants to try out your project. So they google your project name. The user unknowingly ends up at the site of some kid who had no intention infringing on your trademark, but was instead simply trying to give back their hack, for say - GPL compliance. (contrived, but you get the point) In the case of the Fossil project specifically, what sort of steps would make it ok to say hey folks check out fossil hack, it's up on a cloned repo at url abc. Even if one was in the position of a regular contributor, they still might want to do something like this as sort of a public private branch in between contribution worthy revisions. -- C. Thomas Stover Stover Enterprises, LLC ___ 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
Re: [fossil-users] applied DVCS for collaborative work - on the fossil project itself, or otherwise
On Thu, Dec 13, 2012 at 09:27:03AM -0700, Matt Welland wrote: One partial solution available today is to use http://chiselapp.com. Simply use their clone repo feature with regular pull. What is missing is a way to register the fork with the original project. It would be cool if it was possible to submit the URL of the forked repo to the parent. The parent can verify that the URL is a real fork and not some random URL and then make the forks (with description?) browseable on a Forks page. I like this, I should add the ability to easily fork chisel repositories. It would be easy to maintain the association and provide a page to show forks of projects. I'll add this to my chiselapp todo list. Thanks for the idea! -- James Turner ja...@calminferno.net ___ 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] applied DVCS for collaborative work - on the fossil project itself, or otherwise
On Thu, 13 Dec 2012 09:27:03 -0700 Matt Welland estifo...@gmail.com wrote: One partial solution available today is to use http://chiselapp.com. Simply use their clone repo feature with regular pull. What exactly does that do over a regular clone pull? -- www.thomasstover.com ___ 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] applied DVCS for collaborative work - on the fossil project itself, or otherwise
On Thu, Dec 13, 2012 at 11:37 AM, C. Thomas Stover c...@thomasstover.comwrote: On Thu, 13 Dec 2012 09:27:03 -0700 Matt Welland estifo...@gmail.com wrote: One partial solution available today is to use http://chiselapp.com. Simply use their clone repo feature with regular pull. What exactly does that do over a regular clone pull? Nothing really except that chiselapp will regularly pull from the parent. The point I was trying to make is that using chiselapp you can create public forks quite easily. What was missing was a mechanism to aggregate or document the forks so that people looking at a repo can find them. James Turner has indicated that he is interested in adding such a mechanism into chiselapp which I think will be great. I also think that such a feature would be very beneficial if integrated into fossil itself. If I use chiselapp or my own private server to clone the fossil-scm.comsite there is no record of the fork at the fossil-scm site. I personally think that having pointers to forks of the project would potentially stimulate more development activity. Certainly I'd like to have that for my own projects. Being able to pull in just a single branch from one of those forks would be icing on the cake. -- www.thomasstover.com ___ 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] applied DVCS for collaborative work - on the fossil project itself, or otherwise
blabbing I have made some great progress on my continuing quest for fire with Fossil yesterday and today. In this episode, my juggling of over-committed time cycled back around to answering questions about branching and merging in the context of various development models using Fossil. In no way am I ashamed to say this this entire area (not just with Fossil) can be exceedingly complex, and really can make an old dog feel incapable of learning new tricks. Chin up, and persevere. For all the playing around with it is very much worth the headaches. The DVCS model(s) really are powerful time amplifying tools, of which Fossil clearly is the least nonsense, most purposeful winner. /blabbing For example, to experiment with some private changes to an actively developed codebase within a publicly cloneable Fossil project, one simply (honoring licenses, etc): 1. clones it 2. makes a branch 3. hacks 4. occasionally --pull from the official project; and merge with trunk 5. optionally publicly host this repository Now for some questions and observations... If the official project maintainers would like to bring in this branch onto their own Fossil server (either to simply host it, or to attempt a merge) they can do so with a --pull. However this currently would have the consequence of the all or nothing (wiki pages, other branches, tickets) behavior. Even so, having Fossil display and generate diffs so as to allow the changes of choice to be visualized and read clearly before being patched into a forked version (official or otherwise) is still about 1000:1 sanity improvement over emailing diff attachments. A project using Fossil may host some code with a F/OSS license of some kind, but it may or may not have as copyright holders granted the right to re-host things like wiki pages. So this detail would need to be considered before hosting a clone of someone else's project. Again some type of clone/push/pull granularity might be useful to avoid a legal, courtesy, or outright malicious incident. Consider the case of a new user who wants to try out your project. So they google your project name. The user unknowingly ends up at the site of some kid who had no intention infringing on your trademark, but was instead simply trying to give back their hack, for say - GPL compliance. (contrived, but you get the point) In the case of the Fossil project specifically, what sort of steps would make it ok to say hey folks check out fossil hack, it's up on a cloned repo at url abc. Even if one was in the position of a regular contributor, they still might want to do something like this as sort of a public private branch in between contribution worthy revisions. -- C. Thomas Stover Stover Enterprises, LLC ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
