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] (mailto:[email protected])> wrote: > > > On 02/26/12 03:09, [email protected] (mailto:[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] (mailto:[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
