Re: [fossil-users] feature proposal: explicitly public branches
On Thu, Mar 1, 2012 at 18:04, Brian Smith wrote: > 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= 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.. Yes, unique SHA1 hash prefixes would be very useful. And as usual "abcd1234" is a hash and "tag:abcd1234" is a tag. > > 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. > What I meant was that --pushref/--pullref flags are supposed to push/pull individual artifacts. This is mostly useful to selectively resolve phantoms. In the future, if limsync pushref/pushref functionality is exported to the JSON API, one can do some advanced stuff on top of the default limsync functionality. But for now, it is better not to worry about it at all! --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] feature proposal: explicitly public branches
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= 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 (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 tra
Re: [fossil-users] Overwriting binary files on 'update'
On Thu, Mar 1, 2012 at 8:03 AM, Leo Razoumov wrote: > 2012/3/1 Lluís Batlle i Rossell : > > Hello, > > > > in fossil 1.21, I've a modified openoffice file. Then I run "fossil > update", and > > it tells me there is a merge conflict with a binary file, that it cannot > merge. > > > > What I'm surprised about is that fossil overwrites my local changes with > the > > incoming ones. And the file with local changes disappears, only > available again > > on 'fossil undo'. > > > > Should't fossil better leave additional files in the directory, as with > the > > "-baseline", "-original", and "-merge"? > > > > Please, correct me if I am wrong, but I noticed that "fossil update" > also overrides unmanaged files (both binary and text). I am not sure > that their contents are backed up. > "fossil update" will also bring back files that have been "fossil rm"'d and physically removed. It'd be nice to be given the opportunity to abort as this can be a real pain. > > --Leo-- > ___ > 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
Re: [fossil-users] Overwriting binary files on 'update'
2012/3/1 Lluís Batlle i Rossell : > Hello, > > in fossil 1.21, I've a modified openoffice file. Then I run "fossil update", > and > it tells me there is a merge conflict with a binary file, that it cannot > merge. > > What I'm surprised about is that fossil overwrites my local changes with the > incoming ones. And the file with local changes disappears, only available > again > on 'fossil undo'. > > Should't fossil better leave additional files in the directory, as with the > "-baseline", "-original", and "-merge"? > Please, correct me if I am wrong, but I noticed that "fossil update" also overrides unmanaged files (both binary and text). I am not sure that their contents are backed up. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] feature proposal: explicitly public branches
On Thu, Mar 1, 2012 at 9:30 AM, Leo Razoumov wrote: > On Thu, Mar 1, 2012 at 09:16, Richard Hipp wrote: > > On Thu, Mar 1, 2012 at 6: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. > > > > > > Note that there are a several of ways to view check-ins related to a > > branch. For example: > > > > http://www.fossil-scm.org/fossil/timeline?r=experimental > > http://www.fossil-scm.org/fossil/timeline?r=experimental&mionly > > http://www.fossil-scm.org/fossil/timeline?t=experimental > > > > What does "mionly" flag do? I was not able to find any documentation > for it. Look likes it has something to do with merges. > The r=BRANCH parameter normally shows merges into the branch and merges from the branch into other branches. But if you add the mionly parameter, (merge-in only) then only the merges into the branch are shown. > > --Leo-- > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] feature proposal: explicitly public branches
On Thu, Mar 1, 2012 at 09:16, Richard Hipp wrote: > On Thu, Mar 1, 2012 at 6: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. > > > Note that there are a several of ways to view check-ins related to a > branch. For example: > > http://www.fossil-scm.org/fossil/timeline?r=experimental > http://www.fossil-scm.org/fossil/timeline?r=experimental&mionly > http://www.fossil-scm.org/fossil/timeline?t=experimental > What does "mionly" flag do? I was not able to find any documentation for it. Look likes it has something to do with merges. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] feature proposal: explicitly public branches
On Thu, Mar 1, 2012 at 6: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. > Note that there are a several of ways to view check-ins related to a branch. For example: http://www.fossil-scm.org/fossil/timeline?r=experimental http://www.fossil-scm.org/fossil/timeline?r=experimental&mionly http://www.fossil-scm.org/fossil/timeline?t=experimental > > 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 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 feedb
Re: [fossil-users] feature proposal: explicitly public branches
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 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 > wrote: > > On 02/26/12 03:09, altufa...@mail.com wrote: > > Why not ju
[fossil-users] Overwriting binary files on 'update'
Hello, in fossil 1.21, I've a modified openoffice file. Then I run "fossil update", and it tells me there is a merge conflict with a binary file, that it cannot merge. What I'm surprised about is that fossil overwrites my local changes with the incoming ones. And the file with local changes disappears, only available again on 'fossil undo'. Should't fossil better leave additional files in the directory, as with the "-baseline", "-original", and "-merge"? Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
