Brian, for simplicity you might want to follow the selection rules that already exist in fossil web-interface. When I go to the web-interface=>Branches and select a branch I am presented with a partial view of the DAG that fossil thinks is relevant to the branch I chose. For the sake of consistency I would prefer that limsync push/pull uses the same selection rules and transfers the same commits.
To transfer individual commits it would be great if --pushtags and --pulltags accept SHA1 hashes in addition to actual tag names. As a next step, I hope, one can augment limsync with a json API so that power users can do more complex things. --Leo-- P.S. Sorry for top-posting. On Wed, Feb 29, 2012 at 21:32, Brian Smith <[email protected]> wrote: > Hello again, > > Ok, so, it's not quite afternoon, but, it's still the same day. > > Here are some of the basic items that need feedback: > I've marked each question with an asterisk (*) so that you can find my > questions easier. > > Scenario: > You're pulling a specific branch (topic1) that other developers are also > committing on. > You have only ever pulled topic1 branch and nothing else. > > Someone commits to topic1 and then later moves that commit to the mistake > branch. > > As presently implemented, limsync will pull in the control artifact that > made that change, > and that commit will then show up in your copy on the mistake branch, even > though you've > never pulled mistake. > > (*) What do people want to have happen here? I think this is reasonable > behavior because, > the movement of a commit off of the branch you're interactive with is a > valid part of the > history of that branch. I don't yet know what it would take to change that > behavior. > > > Scenario: > Same as above. > > Someone merges into topic1 the branch topic2. > > As presently implemented, limsync will pull in the merge commit, and the > last commit to > topic2, but no other commits. It's necessary to at least pull in every > immediate parent of > a merge commit, but, it only needs to be the manifests. File data could be > excluded. > It's possible to have limsync pull in the complete history of topic2 on such > an event. > > (*) What would people prefer to see with respect to merge commits? > I suppose this could be configurable behavior, but, I'm hesitant to make it > configurable > on the first pass. That should be added later based on demand, probably. > > Scenario: > Same as before. > > Someone creates a new branch topic3 off of some commit of topic1. > > limsync currently will pull in the first commit of that new branch. > Mind you, only the _first_ commit will be pulled in. I don't yet know how it > interacts > with the command 'branch new'. I'll add that to my list of things to test > regardless. > > (*) Does anyone have any preference here? I could probably make it ignore > new branches > off of the branches you're pulling, but, it seems to me that discovering new > lines of history > is valuable. > > That's it for the behavior questions. > > I have a couple user interface and functionality questions as well that > could be > helpful to get feedback on. Though, if nobody has any immediate preferences, > I'll just go ahead and do whatever I want. :) > > Right now, the command line interface is modeled like so (ignoring existing > flags): > > fossil push/pull [--tickets] [--wiki] [--branch NAME]* > > Plus two advanced flags: --pushtags, --pulltags which allow you to specify > any arbitrary > tag name. All of --tickets, --wiki, and --branch, are essentially > implemented in terms of > those two flags. > > --branch, --pushtags, and --pulltags can all be specified multiple times > like so: > > fossil push --branch topic1 --branch topic2 > > (*) Would people prefer a comma separated list of branches/tags ? > > (*) Would it be useful to anyone to be able to specify something like: > > fossil pull --tag release=v1.0 > > So that you could theoretically create repositories that only track tags > with specific values? > > That's it for now. As I put my head back into the code, I'm sure I'll come > up with other questions. > > -B > > On Wednesday, February 29, 2012 at 12:22 PM, Brian Smith wrote: > > Hi, > > Sorry for my radio silence over the weekend. > I have to say, I'm a tad caught off guard by the sudden enthusiasm for this > feature! > > Anyway, what I need most is community feedback on some open questions. > You can find most of my open questions in the fossil-dev archives. > (Unfortunately, it looks like you need to sign up for that list to see > them.) > > Right now, I need to do some other work, but, I'll try to carve out some > time this > afternoon to summarize the open questions and give an overview of what I'd > like > to push into a branch on the master repo once the feature has more testing. > > -B > > On Saturday, February 25, 2012 at 7:37 PM, Leo Razoumov wrote: > > On Sat, Feb 25, 2012 at 21:30, Jan Danielsson > <[email protected]> wrote: > > On 02/26/12 03:09, [email protected] wrote: > > Why not just productize limsync? > > > Going by what Brian Smith has written, it's a question of having time > do work on it and handling a few special cases. > > Brian, if you need any kind of assistance, please let us know. I > really want this feature. > > > I also offered my help to Brian in limsync testing. Right now limsync > still has some bugs. For instance, attempts to pull trunk from main > fossil repo into limsync repo stops well short of its leaf. On the > other hand, when ready limsync should be very useful. > > --Leo-- > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
