Ok, (cross-posting to fossil-dev to move this discussion over after this message)
I've got a few hours of staring at the sync exchange now and I have some thoughts on it: (I'd love feedback on these thoughts!) 1. There seems to be three ways to add this functionality protocol-wise to fossil. The first would make use of the pragma functionality. This has the benefit/downside that older servers would simply ignore the request for specific information and the client would get all data anyways. The next option is to add a new 'verb' (branches perhaps?) to the protocol. This would likely break sync against older servers but would seem to do a less unexpected thing. The last option is to do it completely client-side, however, I can't yet see a way to do that without the server still sending us everything and then the client filtering and throwing away artifacts it's uninterested in. This is appealing from a backwards compatibility standpoint, but, it's rather un-parsimonious resource wise. 2. Is there any interest in having the ability to *Always* push/pull *different* branches? Example: fsl setting pull-branches master fsl setting push-branches trunk fsl pull # this pulls from master # edits on trunk fsl ci fsl push # this pushes trunk fsl merge master fsl sync # changes from master are now visible in trunk The main use case I could see for this is an integrator who was taking changes from non-canonical repositories and merging them into a main repository. 3. Last, as long as we're adding more complicated logic to the sync, it occurred to me that there might be a reason for wanting to treat closed branches specially (without a flag like --closed also applied). I'm not yet sure that there's a compelling reason for it, but, I'm tossing it out there. I suppose it could be used administratively to make sure that dead branches don't get reopened without good reason. Ok, time for sleep, -B On Fri, Oct 21, 2011 at 8:29 PM, Brian Smith <br...@linuxfood.net> wrote: > If I understand you correctly, > > Such a feature would seem to be very difficult to implement in fossil, > since fossil records that information as tags on commits and doing that would > necessitate either rewriting history (bad!), or to rewrite the > information as its > being unpacked and leave it unmodified in the database - which could lead > to very surprising consequences if the repository was rebuilt. > > Re: syncing a subset of branches: I'm sort of tentatively looking over > what it would > take to modify fossil to do that. I'd like for it to be a weekend > project, but I'm not > overly optimistic since my weekend is pretty full at the moment. > > However, current thinking is that the user interface needs the > following changes: > 1. Several settings should be added: sync-branches, sync-tickets, sync-wiki > sync-tickets and sync-wiki should be ON by default in new clones > to preserve the old behavior. > 2. The clone command needs to set the above to whatever you cloned with. > 3. The clone/push/pull/sync commands needs to respect the new flags: > --branches, --tickets, --wiki > 4. specifying one of the new flags to push/pull/sync should not modify > the settings > 5. if you clone with --branches and --tickets, for instance, sync-wiki > should be set to false, but if you only clone with --branches, > sync-wiki and sync-tickets should default to on. > > I'm still in the process of dissecting the protocol used for sync, > once that's done I'll have a better idea of what it'll take > internally to extend it (and surely questions about the best way to go > about that). > > For the moment though, I'd like thoughts on the user facing changes. > > -B > > On Fri, Oct 21, 2011 at 8:01 PM, <ala...@snell-pym.org.uk> wrote: >> Relatedly (so may be easy to do at the same time, or leave hooks to do it >> later), I think it might be useful to pull from a repo with a prefix added >> to all tags/branches. Sort of like git remote branches, to examine some >> changes without them being able to mess up your own state. >> >> Sent from my BlackBerry® wireless device >> >> -----Original Message----- >> From: Jan Danielsson <jan.m.daniels...@gmail.com> >> Sender: fossil-users-boun...@lists.fossil-scm.org >> Date: Sat, 22 Oct 2011 04:36:00 >> To: Fossil SCM user's discussion<fossil-users@lists.fossil-scm.org> >> Reply-To: Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> >> Subject: Re: [fossil-users] feature list? >> >> On 10/22/11 03:44, Richard Hipp wrote: >> [---] >>>> ------ >>>> (2) Add the ability to push/pull/sync just a specific branch, as an >>>> alternative to the current behavior of push/pull/sync of everything. >>>> The current behavior should continue as the default. Single-branch >>>> push/pull/sync should be a command-line option. >>>> ------ >>>> >>>> Should this be interpreted literally: That only pull, push and sync >>>> would support specifying a subset of artifacts -- or should it be >>>> interpreted as including clone as well? >>> >>> Clone too. >>> >>> Also options to push/pull/sync/clone just wiki or tickets. >> >> Is anyone working on this? >> >> >> If there are no takers, I'll have a look at it. >> >> -- >> Kind regards, >> Jan Danielsson >> >> _______________________________________________ >> 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
