Re: [fossil-users] Derived code, not to be pushed public
On Sat, Feb 18, 2012 at 6:42 AM, Leo Razoumov slonik...@gmail.com wrote: On Thu, Feb 16, 2012 at 14:15, Brian Smith br...@linuxfood.net wrote: For what it's worth, I was working on limited branch syncing awhile back. I never got around to merging it back into the master fossil repo, but, I think at least your use case is functional.. http://code.linuxfood.net/pub/repo/fossil-limsync I really ought to finish that up and push it into the master fossil repo. Brian, I cloned your repository and merge limsync into trunk [6c835ea8c7c615]. The merge went very smoothly with no conflicts. I would like to use limsync for my everyday work but am afraid that it may cause data loss or repository corruption. What do you think? It certainly shouldn't cause corruption. But, I wouldn't yet trust it either. The nice thing is that if you encounter problems, you can just do a regular pull and fossil will do the right thing. Or at least, that's if it doesn't cause corruption. I've never seen it cause corruption. This is because the way limsync is implemented is via lying. Essentially, the client announces what it wants, and then the server hangs onto that and lies every time the client asks for an artifact that isn't on the right branch. This is because only the server really knows. This is one of the really nice things about fossil's sync protocol is that it's just a set exchange and then there's a resolution phase afterwards. And, if bits are missing, fossil is very tolerant of that. To anyone who is interested in the details of the limsync changes, you should search the mailing list. I detailed a number of caveats and open questions while I was initially working on it. Because of the way fossil works, there's a number of strange edge cases that other SCMs don't have to deal with. -B ___ 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] Derived code, not to be pushed public
On Sun, Feb 19, 2012 at 4:34 PM, Brian Smith br...@linuxfood.net wrote: On Sat, Feb 18, 2012 at 6:42 AM, Leo Razoumov slonik...@gmail.com wrote: On Thu, Feb 16, 2012 at 14:15, Brian Smith br...@linuxfood.net wrote: For what it's worth, I was working on limited branch syncing awhile back. I never got around to merging it back into the master fossil repo, but, I think at least your use case is functional.. http://code.linuxfood.net/pub/repo/fossil-limsync I really ought to finish that up and push it into the master fossil repo. Brian, I cloned your repository and merge limsync into trunk [6c835ea8c7c615]. The merge went very smoothly with no conflicts. I would like to use limsync for my everyday work but am afraid that it may cause data loss or repository corruption. What do you think? It certainly shouldn't cause corruption. But, I wouldn't yet trust it either. The nice thing is that if you encounter problems, you can just do a regular pull and fossil will do the right thing. Or at least, that's if it doesn't cause corruption. I've never seen it cause corruption. I have not looked at Brian's code. Nevertheless, I want to point out that Fossil repositories are very resistant to corruption. See http://www.fossil-scm.org/fossil/doc/trunk/www/selfcheck.wiki for a description of the steps taken to protect the integrity of individual artifacts. And if you do manage to add an artifact to the repository that is malformed, it will be silently ignored. I suppose it is possible to corrupt a Fossil repository, but I think you'd really have to work at it. This is because the way limsync is implemented is via lying. Essentially, the client announces what it wants, and then the server hangs onto that and lies every time the client asks for an artifact that isn't on the right branch. This is because only the server really knows. This is one of the really nice things about fossil's sync protocol is that it's just a set exchange and then there's a resolution phase afterwards. And, if bits are missing, fossil is very tolerant of that. To anyone who is interested in the details of the limsync changes, you should search the mailing list. I detailed a number of caveats and open questions while I was initially working on it. Because of the way fossil works, there's a number of strange edge cases that other SCMs don't have to deal with. -B ___ 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] Derived code, not to be pushed public
On Thu, Feb 16, 2012 at 14:15, Brian Smith br...@linuxfood.net wrote: For what it's worth, I was working on limited branch syncing awhile back. I never got around to merging it back into the master fossil repo, but, I think at least your use case is functional.. http://code.linuxfood.net/pub/repo/fossil-limsync I really ought to finish that up and push it into the master fossil repo. Brian, I cloned your repository and merge limsync into trunk [6c835ea8c7c615]. The merge went very smoothly with no conflicts. I would like to use limsync for my everyday work but am afraid that it may cause data loss or repository corruption. What do you think? --Leo-- ___ 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] Derived code, not to be pushed public
On Mon, Feb 6, 2012 at 1:53 PM, Lluís Batlle i Rossell vi...@viric.name wrote: On Mon, Feb 06, 2012 at 01:07:30PM -0500, Ron Wilson wrote: Mark your branch private. Anything you want to push can then be merged into a non-private branch. Ah, well, that's fine for personal work. I meant a bit how to do private collaborative work over a public fossil base. Sorry that I did not state all I had in mind clear enough. So you want to have a restricted branch that is shared between a subset of the developers? You could setup a second shared repository and only allow access to the select group, Then have a script that sets your group branch private, pushes to the public repository, then unsets the private attribute on the group branch. ___ 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] Derived code, not to be pushed public
For what it's worth, I was working on limited branch syncing awhile back. I never got around to merging it back into the master fossil repo, but, I think at least your use case is functional.. http://code.linuxfood.net/pub/repo/fossil-limsync I really ought to finish that up and push it into the master fossil repo. From memory, the push and pull commands now have a --branch flag (which may appear multiple times), so you can push/pull only individual branches. The sync command may also have it. Cloning a limited set of branches never got finished, unfortunately. I could clean up the code and remove all of the work in progress for implementing it for clone, just to get at least push/pull out the door. I think that would probably cover quite a few use cases. -B Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, February 16, 2012 at 9:16 AM, Ron Wilson wrote: On Mon, Feb 6, 2012 at 1:53 PM, Lluís Batlle i Rossell vi...@viric.name (mailto:vi...@viric.name) wrote: On Mon, Feb 06, 2012 at 01:07:30PM -0500, Ron Wilson wrote: Mark your branch private. Anything you want to push can then be merged into a non-private branch. Ah, well, that's fine for personal work. I meant a bit how to do private collaborative work over a public fossil base. Sorry that I did not state all I had in mind clear enough. So you want to have a restricted branch that is shared between a subset of the developers? You could setup a second shared repository and only allow access to the select group, Then have a script that sets your group branch private, pushes to the public repository, then unsets the private attribute on the group branch. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org (mailto: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] Derived code, not to be pushed public
On Thu, Feb 16, 2012 at 14:15, Brian Smith br...@linuxfood.net wrote: For what it's worth, I was working on limited branch syncing awhile back. I never got around to merging it back into the master fossil repo, but, I think at least your use case is functional.. http://code.linuxfood.net/pub/repo/fossil-limsync I really ought to finish that up and push it into the master fossil repo. Brian, please, by all means, merge your changes upstream!! pull/push individual branches opens a whole new universe of finely controlled visibility. Cloning individual branches would be nice to have but I can live without it. --Leo-- ___ 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] Derived code, not to be pushed public
On Feb 5, 2012, at 20:47 , Lluís Batlle i Rossell wrote: But I suspect that there are people using fossil and having a reasonable workflow for those cases. I wonder what they use. A lot of care to only pull towards the derivatives? Kind regards, Remigiusz Modrzejewski ___ 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] Derived code, not to be pushed public
On Sun, Feb 5, 2012 at 2:47 PM, Lluís Batlle i Rossell vi...@viric.name wrote: On Sun, Feb 05, 2012 at 02:34:30PM -0500, Leo Razoumov wrote: IMHO, a very important feature is still missing from fossil -- an ability to push or pull a single branch. A great variety of workflows could immediately become possible. Well, even that alone would not be enough. I meant for cases where it is *very important* not to push the work. :) But I suspect that there are people using fossil and having a reasonable workflow for those cases. I wonder what they use. Mark your branch private. Anything you want to push can then be merged into a non-private branch. ___ 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] Derived code, not to be pushed public
On Sun, Feb 5, 2012 at 2:34 PM, Leo Razoumov slonik...@gmail.com wrote: IMHO, a very important feature is still missing from fossil -- an ability to push or pull a single branch. A great variety of workflows could immediately become possible. Perhaps more useful would be the ability to pull a contributor's trunk into a branch in the receiving repository. ___ 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] Derived code, not to be pushed public
On Mon, Feb 06, 2012 at 01:07:30PM -0500, Ron Wilson wrote: On Sun, Feb 5, 2012 at 2:47 PM, Lluís Batlle i Rossell vi...@viric.name wrote: On Sun, Feb 05, 2012 at 02:34:30PM -0500, Leo Razoumov wrote: Well, even that alone would not be enough. I meant for cases where it is *very important* not to push the work. :) But I suspect that there are people using fossil and having a reasonable workflow for those cases. I wonder what they use. Mark your branch private. Anything you want to push can then be merged into a non-private branch. Ah, well, that's fine for personal work. I meant a bit how to do private collaborative work over a public fossil base. Sorry that I did not state all I had in mind clear enough. Additionally, it looked to me that there have been some flaws in the code related to 'private' branches, so I'm understanding that this feature is not under much testing (as in broad usage). Thank you, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Derived code, not to be pushed public
Hello, I wonder how people keep code based on a public fossil repository, but without making the derivaiton public. Of course, with the ability to keep all in sync easily, as if all was in a single VCS. There are the private branches... but I wonder if there are other approaches used by people in this list. I think maybe the private branches feature is not very tested in fossil. For example, hwaci offers extra products for sqlite. How do people at hwaci maintain those sqlite extras in sync? Regards, Lluís. ___ 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] Derived code, not to be pushed public
2012/2/5 Lluís Batlle i Rossell vi...@viric.name: Hello, I wonder how people keep code based on a public fossil repository, but without making the derivaiton public. Of course, with the ability to keep all in sync easily, as if all was in a single VCS. There are the private branches... but I wonder if there are other approaches used by people in this list. I think maybe the private branches feature is not very tested in fossil. IMHO, a very important feature is still missing from fossil -- an ability to push or pull a single branch. A great variety of workflows could immediately become possible. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
