On Wed, 29 Feb 2012 18:32:19 -0800 Brian Smith <br...@linuxfood.net> wrote:
Hello Brian, > 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. Let me say that, in general, I'd happy having same workflow as with Mercurial considering it works reasonable using intuitive choices, although I'm aware that Fossil & Hg have different designs. > 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. It' reasonable. > 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. The present behaviour seems OK, although it seems that pulls the complete history of topic2, but that's probably due to its design. > 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. Is it enough not to get too many conflicts when someone wants to merge it later? > 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. OK. > (*) 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. Hmm, For now I tend to think to ignore new branches. > Right now, the command line interface is modeled like so (ignoring > existing flags): > > fossil push/pull [--tickets] [--wiki] [--branch NAME]* Looks OK. > 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. Nice. > --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 ? I prefer the above, iow, no comma-separated list. > (*) Would it be useful to anyone to be able to specify something like: > > fossil pull --tag release=v1.0 YES. > So that you could theoretically create repositories that only track > tags with specific values? That would be very nice. In hg one can do something like: hg clone --rev v1.0 > That's it for now. As I put my head back into the code, I'm sure I'll > come up with other questions. Thank you very much for your work. Having Fossil with the ability to select individual branches for pull/push would make me zo not think about Hg any longer. ;) Sincerely, Gour -- You have a right to perform your prescribed duty, but you are not entitled to the fruits of action. Never consider yourself the cause of the results of your activities, and never be attached to not doing your duty. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
signature.asc
Description: PGP signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
