On 2/6/17, john lunzer <[email protected]> wrote: > > How is this not a bug?
A "bug" means the software gets the wrong answer. That the software does not match the mental model of new users is not a bug. it is (perhaps) a usability concern that can be addressed, but that is different from a bug. Perhaps your concern stems from the view that a "branch" is somehow a first-class object that is of importance to Fossil. It is not. A branch is just a label that some people find useful for organizing their projects. If you choose to label three or four different paths through the history of the project with the same branch name, that may or may not be confusing to humans, but Fossil simply does not care. Fossil does not use branches or branch names internally. All Fossil does is remember the branch labels as a convenience to the user. I get the impression that you are concerned that because two or more paths have the same branch label that Fossil will somehow get confused about what it going on and mess up the repository. It will not. Again: Fossil looks at branches as merely a notation and labeling convenience to the users and tracks them for that reason, but does not otherwise use them in any way. So if you have some goofy branches, don't worry. You can safely ignore them. They will not hurt anything. > After following the steps above I have a named > branch in my repo, seen with "fossil branch ls" and "fossil ui" that can't > be closed via "fossil merge" by using its name. I should note I can merge > the branch if I use the SHA1 hash. If I'm able to merge the second branch > created using "fossil merge myfirstbranch" and there is still a branch open > named "myfirstbranch", as seen with both ls and ui, why doesn't "fossil > merge myfirstbranch" not close this branch as as well? This is inconsistent > behavior, which I would call a bug. A "branch" is just a tag that propagates to child check-ins. When you use a branch name in a command to refer to a check-in, there could be hundreds or thousands of check-ins that have that tag. Fossil simply picks the most recent, which in 99.9% of cases is exactly what you want. In the rare case where "myfirstbranch" does not refer to the specific check-in you want to merge, then you can always use some other means to identify the check-in, such as a unique SHA1 hash prefix. In 10 years of using Fossil, I cannot recall an occasion when I wanted to merge from anything other than the latest version of a branch. I *almost* wanted to do this a few days ago on SQLite (see https://www.sqlite.org/src/timeline?y=ci&b=97ccf3e4&n=22). I thought I was going to need to check-in [e51dc0ec] into trunk after [e9c9ra1f] had already been committed on the same branch. As it happened, I ended up creating a new branch off of [e51dc0ec] and later merging that new branch into trunk. Either way, because I wanted to base subsequent work off of [e51dc0ec] rather than the tip of the branch it was on, I did have to type a SHA1 prefix at least one time, rather than a branch name. That happens sometimes. Rarely. But it isn't the end of the world. And it isn't a bug. > > Having more than one branch open at the same time with the same name is > ambiguous and creates confusion not only for the user but, as I have shown > by example, for the software as well. I'm think the confusion here is purely in the mind of the user :-) But please do continue working with us to help make Fossil easier for users whose view of branches is shaped by prior exposure to other DVCSes. > > You say that the "recommended solution" is not creating branches with the > same name. If it's already viewed as a bad idea which can cause confusion > why allow it all. We like to reuse branch names. "experimental" and "mistake" are popular branch names that get reused a lot, for example. (https://www.sqlite.org/src/timeline?n=100&r=experimental and https://www.sqlite.org/src/timeline?n=100&r=mistake) > I advocate that a user should not be allowed to open a > new branch by the same name at the same time. If two different users > unknowingly create a branch by the same name and try to sync to the same > repo the naming conflict needs to be resolved. I would bet unless the > effort was coordinated that neither user would want the ambiguity of having > two branches open by the same name. > > In conclusion, I believe Fossil has both a bug (due to inconsistent > behavior) and has made a design decision regarding branch name rules which > causes confusion and which risks more bugs in the future. > > I could upload my repo by I believe it is more effective to follow the > steps I have provided as evidence of the issue. If you have any confusion > please walk through the example with the web ui open, it should clear your > confusion up. > -- D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
