On Thursday, March 1, 2012 at 3:18 AM, Leo Razoumov wrote: > 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. > >
Ok, I think the behavior of the r=<branch> timeline view makes sense. I'll make sure I mirror it as closely as possible. > > To transfer individual commits it would be great if --pushtags and > --pulltags accept SHA1 hashes in addition to actual tag names. > > Hm, so, you would be in favor of a more general notation closer to: --pushrefs --pullrefs, where a 'ref' is a full sha1, or a tag? Would unique prefixes of sha1 hashes be useful too? (Those are currently accepted elsewhere.) Note: I don't really know how feasible that is with the current code, but, I could possibly retarget.. > > As a next step, I hope, one can augment limsync with a json API so > that power users can do more complex things. > > I'm not sure what this would imply. The JSON API is a separate interface, that IIRC doesn't have push/pull capabilities yet. Ostensibly, any addition of push/pull capabilities should mirror the existing functionality. > > --Leo-- > > P.S. Sorry for top-posting. > > On Wed, Feb 29, 2012 at 21:32, Brian Smith <br...@linuxfood.net > (mailto:br...@linuxfood.net)> 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 > > <jan.m.daniels...@gmail.com (mailto:jan.m.daniels...@gmail.com)> wrote: > > > > On 02/26/12 03:09, altufa...@mail.com (mailto:altufa...@mail.com) 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 > > 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 (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 (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
