Re: [fossil-users] Bug in "fossil branch new"
Thus said Richard Hipp on Mon, 06 Feb 2017 14:49:30 -0500: > Rather than break legacy scripts, perhaps a warning message that says > "the new branch has been created but you are not currently on that > branch - type "fossil update BRANCHNAME" to go there" or similar? Come to think of it, what about something like this: http://www.fossil-scm.org/index.html/info/cbde195a118e231f Alternatively, I suppose the info could be moved above this line: http://www.fossil-scm.org/index.html/artifact?ln=164=efbe1da922f3dc43 Then the ``New branch:'' text would be seen last (might make it easier to see). Andy -- TAI64 timestamp: 400058996c6d ___ 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] Bug in "fossil branch new"
Thus said Richard Hipp on Mon, 06 Feb 2017 14:49:30 -0500: > Rather than break legacy scripts, perhaps a warning message that says > "the new branch has been created but you are not currently on that > branch - type "fossil update BRANCHNAME" to go there" or similar? I think a warning should suffice. While I have, on occasion, also forgotten that ``fossil branch new'' doesn't automatically switch, I have gotten into the habit of using ``fossil commit --branch'' because it seems more natural, and doesn't create an extra artifact that exists solely to create a branch (though I can understand why some would prefer this method). Andy -- TAI64 timestamp: 400058996706 ___ 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] Bug in "fossil branch new"
Thus said "Martin S. Weber" on Mon, 06 Feb 2017 18:10:15 +0100: > Well, given fossil's CLI requires BRANCH-NAME as input, how can the > following commit not go to the same branch? Because it doesn't matter what the name of the branch is. It's just a tag. What is really critical is the BASIS. When I run: fossil branch new test trunk That takes the tip of trunk as the BASIS and adds an empty artifact that has a branch tag called test. When I run: fossil commit --branch test The BASIS is automatically selected as the current checkin that is your working checkout. If I am already ``on branch test'' and I run: fossil commit --branch test Again, it takes the current checkout as the BASIS (which just happens to be ``on the branch'') and adds the test branch tag to the commit. In the timeline, of course they will show up as being on the same branch. Now, if instead, I had run: fossil update trunk fossil commit --branch test Then there would be an additional branch by the same name coming off of trunk, because the BASIS is now unrelated to the previous branch named test. > Imagine you have two same-named branches in different parts of your > version graph, when you select one of these, how would you know which > of these you selected? You can't, except by inspection of the content. I believe Fossil always chooses the tip of the name in question, so to claim that one cannot know is simply to state that one hasn't yet learned the tool sufficiently to know that Fossil chooses the tip. This is why the OP got a no-op when trying to merge his branch because the tip of the named branch had already been merged. How is this behavior any different than when I run: fossil branch new newname trunk How does fossil pick the BASIS? One has to learn that it picks the tip, not some random, arbitrary node along the timeline of trunk. > Again, IMHO, this needs to be revisited to be human-friendly. @drh: > how would you, from the output of fossil branch ls, select the branch > head that equates to version e943565869 ? You mean something like: fossil leaves --bybranch --multiple Arguably, it woudl be nice for ``fossil leaves'' to take a specific branch tag so it could restrict the search to just that one branch. Andy -- TAI64 timestamp: 400058996681 ___ 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] Git just got shallow and sparse clones
Just to contribute my 2 cents to this discussion, for our workflow I'd find sparse clones much more useful than shallow ones, although I can see how deep history can slow initial clone, and that past certain point is rarely useful. It's not our problem - but we have thousands of separate source files in modules that are directory subtrees. Yes, we split those in different Fossil repos, but this approach introduces dependencies and repo management overheads. It's easier to have a single encompassing repo than 30 separate ones, especially if documentation and tickets are involved. There is also IP protection aspect. Being able to clone a certain directory only from the source tree would allow us to restrict the third party developers to see just what they are supposed to see and are allowed to work on. From that perspective sparse clones would have to be 'special' in a sense that you can't sync fully on demand afterwards. This probably means special privilege with list of directory globs an user is allowed to clone sparsely. I am not quite sure how would it all work in Fossil though. The sparse clone from a dir would have to fetch all the check-ins that contain changes to affected files, but drop the other artifacts outside the dir. I suppose we could have missing artifact warnings on update/status/diff (similar to current missing common ancestor warnings in certain merge scenarios), but it will be nice if Fossil is aware that repo is a special sparsely cloned one, and interpret those missing artifacts by showing (or hiding, if preferred) appropriate warnings to avoid confusion. Finally, there is a question of wikis and tickets. Following this model sparse clone would not fetch them, but perhaps it is more useful if this is governed by existing user wiki/ticket privileges. S. Original Message From: Warren Young Sent: Tuesday, 7 February 2017 10:58 To: Fossil SCM user's discussion Reply To: Fossil SCM user's discussion Subject: Re: [fossil-users] Git just got shallow and sparse clones On Feb 6, 2017, at 4:49 PM, Warren Youngwrote: > >> allow cloning a repository “shallowly" > > That’s not what I mean by “shallow,” since according to the docs,[1] Oh, I see the --no-single-branch bit now. Sigh, another confusing Git default. Even so, it still doesn’t quite do what I want: - I want to give --depth in days, not checkins. - I want to allow the cloned-from repository to set a sensible default, so that very large repos can require that cloners specify something like --deep to get everything. Personally, I don’t need this for my own repositories. I’m just putting out ideas to handle extremely large repos. As for my second point above, I’d have been happy if the Linux kernel source repo I checked out onto a Raspberry Pi had only given me the past 30 days or so, without me having to know about --depth. I only wanted --depth=1 anyway. ___ 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] Bug in "fossil branch new"
On Feb 6, 2017, at 9:18 AM, Richard Hippwrote: > > Does anybody else having any feelings one way or another about this? I’m not sure I’ve run into *quite* the same case, but a related one I did run into recently was trying to migrate from a “release” tag (as Fossil itself uses) to a “release” branch.[*] You can see some of the circus this caused here, as it’s a public repo: https://tangentsoft.com/pidp8i/timeline?r=release=2016-12-23 [*] Why use a branch instead of a tag? Because I want the binary OS images I create from the current release version to remain pinned to the release branch, so that if someone using one of those OS images says “fossil update” in the source checkout directory — which remains on the OS images — they get the current release, rather than get sent back to the trunk. You may be happy to know that this software project is also using autosetup, by the way. And if any of you think PDP-8s were cool: https://tangentsoft.com/pidp8i/wiki?name=Warren%27s+PiDP-8/I+System ___ 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] Git just got shallow and sparse clones
On Feb 6, 2017, at 4:49 PM, Warren Youngwrote: > >> allow cloning a repository “shallowly" > > That’s not what I mean by “shallow,” since according to the docs,[1] Oh, I see the --no-single-branch bit now. Sigh, another confusing Git default. Even so, it still doesn’t quite do what I want: - I want to give --depth in days, not checkins. - I want to allow the cloned-from repository to set a sensible default, so that very large repos can require that cloners specify something like --deep to get everything. Personally, I don’t need this for my own repositories. I’m just putting out ideas to handle extremely large repos. As for my second point above, I’d have been happy if the Linux kernel source repo I checked out onto a Raspberry Pi had only given me the past 30 days or so, without me having to know about --depth. I only wanted --depth=1 anyway. ___ 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] Git just got shallow and sparse clones
On Feb 4, 2017, at 6:07 AM, Konstantin Khomoutovwrote: > > commit 016e6ccbe03438454777e43dd73d67844296a3fd > Author: Johannes Schindelin > Date: Mon Oct 30 20:09:29 2006 +0100 > >allow cloning a repository “shallowly" That’s not what I mean by “shallow,” since according to the docs,[1] it only works for a single branch. It’s also not clear to me that there’s a way to pull more history at need with this mechanism. If I’m online, and I step back one checkin on a branch past the files I have locally, will it go pull what it needs transparently from the repo I originally cloned from? To me, a shallow clone says “give me the most recent history at the tip of all open branches, and fetch more at need.” This Git VFS sounds like an extreme form of that, where the initial clone depth is 0. I’d prefer something that copies more like 30 days to my local machine on the initial checkout, so that I could immediately go off-line and have an excellent chance of still having everything I needed. All of this is is an effort to avoid sending the deep history of a repository — at least on initial clone — which most of the time you never need. A secondary use of DVCSes is widespread total-repository replication, but for that you can trickle the history in over the course of days, if need be. For day-to-day use, you rarely need deep history. [1]: https://www.git-scm.com/docs/git-clone#git-clone---depthltdepthgt > commit ed5336a7541e19b267de53afc8d15cffdbde8286 > Author: Nguyễn Thái Ngọc Duy > Date: Thu Aug 20 20:47:05 2009 +0700 > >Introduce "sparse checkout” According to Stack Overflow,[2] you still get all of the remote artifacts in your local repo clone when you do this, subject of course to --depth and such. What I mean by “narrow” is that it only clones a particular subdirectory, or some other pattern match, as Subversion allowed. For example, if I have three top-level directories in my repository, A, B, and C, I’d like to be able to say: $ fossil clone --narrow B https://my-project.org B.fossil which Fossil would realize means I want only B and its children. (We can argue separately over the syntax.) A nice side effect is that this would let you “shard” a large repository, since the local B.fossil clone could be re-shared separately. I have multiple cases here where I put multiple projects in a single repository, because Subversion encouraged that, and now I want them broken up into separate repositories, because Fossil likes that better. If the A, B, and C sub-trees are the same size, I expect this narrow clone to take about 1/3 the time as a full clone, and take about 1/3 the disk space. [2]: http://stackoverflow.com/q/2336580 ___ 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] Bug in "fossil branch new"
+1 This would also guard against unplanned/accidental use of same branch name in a repo with tens of older inactive branches one cannot possible remember at all times. -Original Message- From: Richard Hipp Sent: Monday, February 06, 2017 6:18 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Bug in "fossil branch new" On 2/6/17, Richard Hippwrote: That is correct, and it is by design. Fossil allows any number of branches to share the same name. On second thought, perhaps it would be worthwhile to enhance Fossil so that it issued a warning if you include a --branch argument on "fossil commit" with the same name as an existing open branch, and actually fail the commit unless the --force flag is also present. Perhaps such a change would make Fossil easier to transition to from other systems. Does anybody else having any feelings one way or another about this? -- 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 ___ 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] Bug in "fossil branch new"
A warning would minimally address the issue but there would still be a behavioral inconsistency with "fossil commit --branch" which does automatically move you into the new branch. This inconsistency opens the door to confusion. That said, I think both "fossil branch new" and "fossil commit --branch" should provide feedback as to which branch is "active". This explicit communication will help new users regardless of the decided behavior. On Mon, Feb 6, 2017 at 2:50 PM, jungle Boogiewrote: > On 6 February 2017 at 11:49, Richard Hipp wrote: > > Rather than break legacy scripts, perhaps a warning message that says > > "the new branch has been created but you are not currently on that > > branch - type "fossil update BRANCHNAME" to go there" or similar? > > I'd prefer a warning over a assumed automatic update. > > > -- > --- > inum: 883510009027723 > sip: jungleboo...@sip2sip.info > ___ > 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] Bug in "fossil branch new"
On 6 February 2017 at 11:49, Richard Hippwrote: > Rather than break legacy scripts, perhaps a warning message that says > "the new branch has been created but you are not currently on that > branch - type "fossil update BRANCHNAME" to go there" or similar? I'd prefer a warning over a assumed automatic update. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info ___ 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] Bug in "fossil branch new"
On 2/6/17, john lunzerwrote: > One more thing I think is necessary to mostly eliminate the confusion. > Currently "fossil branch new BRANCHNAME" is not followed by an automatic > "fossil update BRANCHNAME". This I think will be surprising when the user > goes to do their first "fossil commit" thinking they are committing to the > branch they just opened. That might be reasonable. I personally never use "branch new" myself, so I don't really care. But if the "branch new" semantics change, it might break some legacy scripts. Who else would like to see "fossil branch new BRANCHNAME" automatically update to the new branch? Who would have scripts broken by such a change? Rather than break legacy scripts, perhaps a warning message that says "the new branch has been created but you are not currently on that branch - type "fossil update BRANCHNAME" to go there" or similar? -- 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] Bug in "fossil branch new"
On 2/6/17, john lunzerwrote: > > 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=97ccf3e4=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=experimental and https://www.sqlite.org/src/timeline?n=100=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 d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org
Re: [fossil-users] Bug in "fossil branch new"
One more thing I think is necessary to mostly eliminate the confusion. Currently "fossil branch new BRANCHNAME" is not followed by an automatic "fossil update BRANCHNAME". This I think will be surprising when the user goes to do their first "fossil commit" thinking they are committing to the branch they just opened. On Mon, Feb 6, 2017 at 2:08 PM, john lunzerwrote: > Haha, please disregard my previous message. You posted while I was still > typing the other. Your action will mostly take care of the issue. Thank you > for considering my situation. > > If I may ask though, if autosync is off how would the situation of two > developers creating a branch by the same name and then manually syncing to > a repo play out? > > On Mon, Feb 6, 2017 at 1:40 PM, Richard Hipp wrote: > >> On 2/6/17, bch wrote: >> > I haven't ever run into this issue, but what you're wondering about >> sounds >> > reasonable on the surface. "Principle of least surprise", and all... >> > >> >> The trunk version of Fossil will now only permit the --branch option >> on a "fossil commit" if the named branch either does not exist or is >> closed or the --force flag is used. >> >> It turns out the "fossil branch new" command was already configured to >> fail if the branch already existed. The "fossil branch new" command >> is more restrictive in that it does not allow a --force option and it >> refuses to create a new branch with an existing name even if the >> existing branch is closed. >> >> The existing "branch list" shows branches as closed if their most >> recent check-in is closed. But there could still be older leaf >> check-ins that are open on that branch. This is the case for the >> "experimental" branch which as an old open leaf at >> https://www.fossil-scm.org/fossil/timeline?c=b21df7ec - the new >> "fossil branch info" command is more exacting and shows this branch as >> being open and identifies the check-in that is holding it open. >> >> Developer policy: Let's keep the [b21df7ec] check-in open as a test >> case for branches where recent leaves are closed but there exists an >> older leaf that is still open. >> >> -- >> 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 >> > > ___ 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] Bug in "fossil branch new"
Haha, please disregard my previous message. You posted while I was still typing the other. Your action will mostly take care of the issue. Thank you for considering my situation. If I may ask though, if autosync is off how would the situation of two developers creating a branch by the same name and then manually syncing to a repo play out? On Mon, Feb 6, 2017 at 1:40 PM, Richard Hippwrote: > On 2/6/17, bch wrote: > > I haven't ever run into this issue, but what you're wondering about > sounds > > reasonable on the surface. "Principle of least surprise", and all... > > > > The trunk version of Fossil will now only permit the --branch option > on a "fossil commit" if the named branch either does not exist or is > closed or the --force flag is used. > > It turns out the "fossil branch new" command was already configured to > fail if the branch already existed. The "fossil branch new" command > is more restrictive in that it does not allow a --force option and it > refuses to create a new branch with an existing name even if the > existing branch is closed. > > The existing "branch list" shows branches as closed if their most > recent check-in is closed. But there could still be older leaf > check-ins that are open on that branch. This is the case for the > "experimental" branch which as an old open leaf at > https://www.fossil-scm.org/fossil/timeline?c=b21df7ec - the new > "fossil branch info" command is more exacting and shows this branch as > being open and identifies the check-in that is holding it open. > > Developer policy: Let's keep the [b21df7ec] check-in open as a test > case for branches where recent leaves are closed but there exists an > older leaf that is still open. > > -- > 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 > ___ 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] Bug in "fossil branch new"
On Mon, Feb 6, 2017 at 11:13 AM, Richard Hippwrote: > > > > > After the second "fossil commit --branch myfirstbranch" no new branch is > > created, commited to the same branch as the after the first "fossil > commit > > --branch myfirstbranch" > > Actually, it did create a new branch off of the first branch. But as > both branches have the same name, you don't notice it on the timeline. > If you were to change the name of the first branch, you would notice > that the second branch name remained unaltered. That's the only way > you could tell that you did in fact create a new branch. This is where what I'm seeing doesn't line up with what you're telling me. The "fossil ui" *visually* shows 2 branches with the same name after "fossil branch new" and the first "fossil commit --branch". Additionally, If I perform a "fossil branch ls" at this point only "myfirstbranch" and "trunk" show up. This is inconsistent. After the second "fossil commit --branch" there are sill visually 2 branches on the web ui. If what you're telling me was true and consistent then I should visually see 3 branches after the second "fossil commit --branch". But that isn't the case, there is an inconsistency in the behavior. > > > > After fossil merge myfirstbranch, then commit, only the branch created > with > > "fossil commit" is merged to trunk and there is still an open leaf on a > > branch with name "myfirstbranch" > > > > Listing branches still shows that myfirstbranch exists. > > > > Trying to merge again gives the message of "no-op", a force merely tries > to > > merge the branch created by "fossil commit" again. > > > > The open leafed branch cannot be merged. > > > > I believe this is a bug. I'm bewildered as to how to resolve this > > situation. > > This isn't really a problem that needs resolving, in the sense that > Fossil does not care. You might want to close some of the branch > heads just to keep your repository tidy, but that is an aesthetic > concern that (while important to human readers) does not affect the > integrity of the repository. > > I got a little confused with your description. If you can share your > repository, someone can probably guide you toward how to mark the > unwanted branches as "closed" and thus resolve the situation. > How is this not a bug? 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. 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. 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. 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. ___ 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] Bug in "fossil branch new"
On 2/6/17, bchwrote: > I haven't ever run into this issue, but what you're wondering about sounds > reasonable on the surface. "Principle of least surprise", and all... > The trunk version of Fossil will now only permit the --branch option on a "fossil commit" if the named branch either does not exist or is closed or the --force flag is used. It turns out the "fossil branch new" command was already configured to fail if the branch already existed. The "fossil branch new" command is more restrictive in that it does not allow a --force option and it refuses to create a new branch with an existing name even if the existing branch is closed. The existing "branch list" shows branches as closed if their most recent check-in is closed. But there could still be older leaf check-ins that are open on that branch. This is the case for the "experimental" branch which as an old open leaf at https://www.fossil-scm.org/fossil/timeline?c=b21df7ec - the new "fossil branch info" command is more exacting and shows this branch as being open and identifies the check-in that is holding it open. Developer policy: Let's keep the [b21df7ec] check-in open as a test case for branches where recent leaves are closed but there exists an older leaf that is still open. -- 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] Bug in "fossil branch new"
On 2017-02-06 11:13:46, Richard Hipp wrote: > (...) > Probably you are coming from a different DVCS that requires branches > to be created in advance of the commit and that also requires branch > names to be unique. Fossil has neither of these constraints, and so > it operates a little differently from what you might be used to. Well, given fossil's CLI requires BRANCH-NAME as input, how can the following commit not go to the same branch? To me, this is a bug in fossil as well, and confusing behaviour on top of it. I've learned a while ago to not create a branch before usage because it's confusing to the user, and that is a bad thing (tm). If multiple branches of the same name exist, the fossil CLI does not qualify for adressing these. That's a bad thing (tm). Branches do not have an identity. The name is useless to fossil and user. IMHO it's time to stop defending this design principle and select a better design principle that stops confusing users and allows them to actually identify and address a branch using fossil's native CLI. Imagine you have two same-named branches in different parts of your version graph, when you select one of these, how would you know which of these you selected? You can't, except by inspection of the content. This could be mitigated, by keeping the same design, with the CLI actually outputting an identity of the branch that can be used to select that specific branch. If the name is but a tag, do output the actual identity. Problem then becomes one of the user-unfriendliness of entering hashes for symbolic names (why have symbolic names if they are worthless?). Again, IMHO, this needs to be revisited to be human-friendly. @drh: how would you, from the output of fossil branch ls, select the branch head that equates to version e943565869 ? fossil update dev will warn about the multiple leaves, and wrongly claim that one of these two is "current". Actually both are "current" when you assume that the name does not identify a branch, because these two are completely separate identities. So the CLI actually is inconsistent with the design of fossil. If you continue the line of thought that branch names are not to be unique, one could as well create a fresh branch for each checkin. So, say, there's five commits on trunk, that would be five different-but-samely-named "trunk" branches in the repo. Madness! Regards, -Martin $ fossil new yo.fossil project-id: 8144232186a07805496c756830b99307000df301 server-id: b837d648f0424d4b9c98667e195bc56674c76774 admin-user: phaeton (initial password is "f51de9") $ mkdir yo $ cd yo /home/phaeton/tmp/bla/yo $ fossil open ../yo.fossil project-name: repository: /usr/home/phaeton/tmp/bla/yo/../yo.fossil local-root: /usr/home/phaeton/tmp/bla/yo/ config-db:/home/phaeton/.fossil project-code: 8144232186a07805496c756830b99307000df301 checkout: d2efb912b99c568ad0cee694c5ce9f50396c60f6 2017-02-06 16:58:31 UTC tags: trunk comment: initial empty check-in (user: phaeton) check-ins:1 $ touch a $ fossil add a ADDED a $ fossil ci -m 'a.' a New_Version: 6025c147db18aaf23820068b4fb05635d2729de6 $ echo yo >> a $ fossil ci -m 'a.dev' --branch dev a New_Version: e943565869bf485986a8d588219399a60a9105ed $ fossil timeline === 2017-02-06 === 17:00:05 [e943565869] *CURRENT* a.dev (user: phaeton tags: dev) 16:58:55 [6025c147db] a. (user: phaeton tags: trunk) 16:58:31 [d2efb912b9] initial empty check-in (user: phaeton tags: trunk) +++ no more data (3) +++ $ fossil update trunk UPDATE a --- updated-to: 6025c147db18aaf23820068b4fb05635d2729de6 2017-02-06 16:58:55 UTC tags: trunk comment: a. (user: phaeton) changes: 1 file modified. "fossil undo" is available to undo changes to the working checkout. $ echo oy >> a $ fossil ci -m 'oy!' a New_Version: 1ff2fa69b5a21571dbb3b60b63c5155686f10107 $ echo dev >> a $ fossil ci -m 'oy.dev' --branch dev a New_Version: 41b2cea47b0f23c6339222583f6cc9d07660ac8d $ fossil timeline === 2017-02-06 === 17:01:56 [41b2cea47b] *CURRENT* oy.dev (user: phaeton tags: dev) 17:01:32 [1ff2fa69b5] oy! (user: phaeton tags: trunk) 17:00:05 [e943565869] a.dev (user: phaeton tags: dev) 16:58:55 [6025c147db] *BRANCH* a. (user: phaeton tags: trunk) 16:58:31 [d2efb912b9] initial empty check-in (user: phaeton tags: trunk) +++ no more data (5) +++ $ fossil branch ls * dev trunk $ fossil update dev --- checkout:
Re: [fossil-users] Bug in "fossil branch new"
I haven't ever run into this issue, but what you're wondering about sounds reasonable on the surface. "Principle of least surprise", and all... -bch On Feb 6, 2017 08:18, "Richard Hipp"wrote: > On 2/6/17, Richard Hipp wrote: > > > > That is correct, and it is by design. Fossil allows any number of > > branches to share the same name. > > On second thought, perhaps it would be worthwhile to enhance Fossil so > that it issued a warning if you include a --branch argument on "fossil > commit" with the same name as an existing open branch, and actually > fail the commit unless the --force flag is also present. Perhaps such > a change would make Fossil easier to transition to from other systems. > Does anybody else having any feelings one way or another about this? > -- > 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 > ___ 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] Bug in "fossil branch new"
On 2/6/17, Richard Hippwrote: > > That is correct, and it is by design. Fossil allows any number of > branches to share the same name. On second thought, perhaps it would be worthwhile to enhance Fossil so that it issued a warning if you include a --branch argument on "fossil commit" with the same name as an existing open branch, and actually fail the commit unless the --force flag is also present. Perhaps such a change would make Fossil easier to transition to from other systems. Does anybody else having any feelings one way or another about this? -- 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] Bug in "fossil branch new"
On 2/5/17, john lunzerwrote: > Here is the test sequence: > > cd fossils > fossil new testrepo.fossil > mkdir ../testrepo > cd ../testrepo > fossil open ../fossils/testrepo.fossil > fossil branch new myfirstbranch trunk > fossil commit --allow-empty --branch myfirstbranch -m "A new branch" > fossil commit --allow-empty --branch myfirstbranch -m "A new branch, > again?" > fossil update trunk > fossil merge myfirstbranch > fossil commit -m "merged myfirstbranch" > fossil branch ls > fossil merge myfirstbranch --force > fossil commit -m "merged myfirstbranch" --allow-empty > > After "fossil branch new" a new branch is created. > > After the first "fossil commit --branch myfirstbranch" another branch is > created by the same name as the first branch. That is correct, and it is by design. Fossil allows any number of branches to share the same name. This does not cause any problems for Fossil itself, though it might perhaps be confusing to users. The recommended solution is simply to not create multiple branches with the same name :-) Probably you are coming from a different DVCS that requires branches to be created in advance of the commit and that also requires branch names to be unique. Fossil has neither of these constraints, and so it operates a little differently from what you might be used to. > > After the second "fossil commit --branch myfirstbranch" no new branch is > created, commited to the same branch as the after the first "fossil commit > --branch myfirstbranch" Actually, it did create a new branch off of the first branch. But as both branches have the same name, you don't notice it on the timeline. If you were to change the name of the first branch, you would notice that the second branch name remained unaltered. That's the only way you could tell that you did in fact create a new branch. > > After fossil merge myfirstbranch, then commit, only the branch created with > "fossil commit" is merged to trunk and there is still an open leaf on a > branch with name "myfirstbranch" > > Listing branches still shows that myfirstbranch exists. > > Trying to merge again gives the message of "no-op", a force merely tries to > merge the branch created by "fossil commit" again. > > The open leafed branch cannot be merged. > > I believe this is a bug. I'm bewildered as to how to resolve this > situation. This isn't really a problem that needs resolving, in the sense that Fossil does not care. You might want to close some of the branch heads just to keep your repository tidy, but that is an aesthetic concern that (while important to human readers) does not affect the integrity of the repository. I got a little confused with your description. If you can share your repository, someone can probably guide you toward how to mark the unwanted branches as "closed" and thus resolve the situation. -- 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