Re: [fossil-users] Bug in "fossil branch new"

[Andy Bradford]

Thus said john lunzer on Sun, 05 Feb 2017 13:06:04 -0500:

> 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
> ...
> I believe this is a bug. I'm bewildered as to how to resolve this situation.

I  believe  nobody  mentioned  one  low-hassle  way  that  resolve  this
situation is to update to that branch and run fossil merge. This is done
anytime you end up with a fork in trunk (or any branch for that matter):

$ fossil up myfirstbranch   
---
checkout: 286e7146246a71139eb512510f7cacb729dde91a 2017-02-09 14:17:35 UTC
tags: myfirstbranch
comment:  A new branch, again? (user: amb)
changes:  None. Already up-to-date
WARNING: multiple open leaf check-ins on myfirstbranch:
  (1) 2017-02-09 14:17:35 [286e714624] (current)
  (2) 2017-02-09 14:15:32 [e07533879c]
$ fossil merge
Merging fork [e07533879c] at 2017-02-09 14:15:32 by amb: "Create new branch
named "myfirstbranch""
$ fossil commit -m resolved
New_Version: 4af67471394a024d13b339df440f60d7b3e0b4b6
$ fossil update trunk
---
checkout: e32235e4845f01c072b0f3c83211a89ab99b6fbe 2017-02-09 14:17:50 UTC
tags: trunk
comment:  merged myfirstbranch (user: amb)
changes:  None. Already up-to-date
$ fossil merge --integrate myfirstbranch
$ fossil commit -m done
Closed: 4af67471394a024d13b339df440f60d7b3e0b4b6
New_Version: 8ad174708464929a4870310f076cf82955260ea7

Andy
-- 
TAI64 timestamp: 4000589c7b5d


___
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"

[Tony Papadimitriou]

Hmm, but isn't it usually the newbies that do NOT read any documentation? :)

However, if this gets implemented here's a somewhat crazier thought to make 
it ever better for the general public:


fossil set newbie-mode = 

where  is blank indicating "I don't know what I'm supposed to be doing 
here" so fossil will print the whole manual for each command together with 
relevant Wikipedia links as to what an SCM is good for along with real-life 
examples of success stories,
or  is 'youtube' where all help is made of video clips of the 
corresponding concepts or command actions,
or  is 'gui' for the command-line impaired where the command-line 
interface will be completely disabled and everything will be possible from 
the GUI,
or  is 'git' indicating I come from the git world and I refuse to 
learn fossil so I want all commands to show me the git equivalent way,  or 
even better, fossil should accept git commands directly,
or  is 'expert' indicating that all help should be single-liners 
referring to all commands and options with their minimum required text and 
describing all actions with just mathematical symbols,
or  is 'false' for keeping it the way it is now (merely for backwards 
compatibility as I'm sure the majority will want to switch to one of the new 
fancier modes),

... space reserved for additional brainstorming ...

(Now, I hope nobody took this seriously.)

-Original Message- 
From: Richard Hipp


Here is a crazy, crazy thought:

Suppose we put lots and lots of extra text on many of the Fossil
commands, explaining
what just happened and the current repository state, after every
command.  Then provide a command like:

fossil set newbie-hints off --global

That will turn off all the extra verbiage after users get comfortable
with the system.
--
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"

[Andy Bradford]

Thus said "Martin S. Weber" on Tue, 07 Feb 2017 17:04:00 +0100:

> Well,  worthless in  its  ultimate  ratio in  its  current state  (aka
> playing devil's  advocate). Deterministically picking the  wrong thing
> doesn't help. See the email with the fossil output. If I can only pick
> the "other" dev branch by its hash,  then the name of that "other" dev
> branch has become worthless, as it will not resolve to the older one.

I don't think it's entirely worthless, anymore than having two people in
the same room at the same time both having the same name. To address one
or the other, some other indication must be made; for example, one might
move  closer to  the one  that is  intended to  be addressed,  or use  a
nickname, or some other thing.

If I have 2  branches by the same name, I move closer  to the one I want
using the UUID, then further  commits at this point *will* automatically
be applied to that particular instance  of the same branch name, and not
the  most  recent branch  by  that  name. By  that  measure,  it is  not
worthless  because when  I finally  spin  up Fossil  UI to  look at  the
history I  will see the  progress of the  individual branches just  as I
expect.

It's interesting to  note that when Fossil was  first publicly released,
there was no  concept of a ``branch'' but only  forks. Notice that there
are 2 long-term trunks and a number of temporary 3rd trunks:

https://www.fossil-scm.org/index.html/timeline?unhide=on=25=all==exact=fff234b77cc774ca

How did one resolve the  difference between the development on different
forks of trunk? UUID.

Thanks,

Andy
-- 
TAI64 timestamp: 4000589a3b24


___
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"

[Andy Bradford]

Thus said Richard Hipp on Tue, 07 Feb 2017 10:24:46 -0500:

> Suppose we  put lots  and lots  of extra  text on  many of  the Fossil
> commands,  explaining what  just happened  and the  current repository
> state, after every command. Then provide a command like:
> 
>  fossil set newbie-hints off --global

No thanks. :-)

As it turns out, it looks like there may have been some code at one time
that output a warning:

https://www.fossil-scm.org/index.html/artifact?ln=165,174=efbe1da922f3dc43

Personally I find the show_common_info  more interesting to look at than
a warning, but I'm also fine leaving ``fossil branch new'' as-is.

As I  said in another  email, ``fossil  branch new'' behavior  should be
familiar to anyone  who uses ``git branch ''  which also does
not even output a commit hash, or give other details.

Andy
--
TAI64 timestamp: 4000589a1f1d
___
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"

[Andy Bradford]

Thus said john lunzer on Tue, 07 Feb 2017 10:39:49 -0500:

> If   you're  avoiding   "fossil   branch  new"   because  it   doesn't
> automatically switch and  you got confused about  the behavior doesn't
> that help show that it makes sense to automatically switch by default?

Not that  this supports Fossil's  choice to  not switch by  default, but
neither does ``git branch newbranch'' automatically switch branches. One
must  follow ``git  branch newbranch''  with ``git  checkout newbranch''
before the following commit will land on the new branch.

Andy
--
TAI64 timestamp: 4000589a1dbc
___
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"

[Richard Hipp]

On 2/7/17, john lunzer  wrote:
> There is a risk
> of drowning important information which would do the opposite of helping
> "newbies".

Agreed.  Finding the right balance is tricky.

-- 
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"

[john lunzer]

I think there is merit to this thought but I'd be careful. There is a risk
of drowning important information which would do the opposite of helping
"newbies".

On Tue, Feb 7, 2017 at 10:24 AM, Richard Hipp  wrote:

> On 2/7/17, Andy Bradford  wrote:
> >
> > Maybe this isn't even sufficient, but I do believe it's an improvement.
> >
>
> Here is a crazy, crazy thought:
>
> Suppose we put lots and lots of extra text on many of the Fossil
> commands, explaining
> what just happened and the current repository state, after every
> command.  Then provide a command like:
>
>  fossil set newbie-hints off --global
>
> That will turn off all the extra verbiage after users get comfortable
> with the system.
> --
> 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"

[Martin S. Weber]

On 2017-02-07 07:59:03, Andy Bradford wrote:
> Thus said "Martin S. Weber" on Tue, 07 Feb 2017 11:07:55 +0100:
> 
> > thanks for proving my point.
> 
> You're welcome. I  never said branch names don't identify  a branch, nor
> that they  are meaningless.  

drh said branch names don't identify a branch, not you. If names did identify
branches, there would be no way to have two separate branches of the same 
name, as the name would uniquely identify a branch. It doesn't, though.

> I said  that when  you use  ``fossil branch
> new'' that  it doesn't imply that  the following commit will  be on that
> branch.

a fossil update following the branch new would be more user-friendly indeed,
at least IMHO.

My point is, what is the rationale for names not identifying branches
uniquely. Why can I multiple branches off of several basis that have the
same name? See my previous email with the fossil command log output how
even fossil assumes the samely named branches are the same (by outputting
one leaf as "current" and not the other, whereas, if these are indeed
separate branches, both leaves of the same-named branch name need to
be "current").

> 
> And given the following:
> 
> > 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?).
> 
> Does not  Fossil allow  the use  of names for  most operations  and will
> attempt to  resolve them  in a deterministic  fashion? Who  claimed that
> they are worthless?

Well, worthless in its ultimate ratio in its current state (aka playing
devil's advocate). Deterministically picking the wrong thing doesn't 
help. See the email with the fossil output. If I can only pick the "other"
dev branch by its hash, then the name of that "other" dev branch has become
worthless, as it will not resolve to the older one.

Regards,
-Martin
___
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"

[john lunzer]

If you're avoiding "fossil branch new" because it doesn't automatically
switch and you got confused about the behavior doesn't that help show that
it makes sense to automatically switch by default?

I think the most "logical" design would be for the behavior of both branch
creation methods to match as closely as possible. In this case both methods
should switch the branch just created and tell the user it switched.

If you want to retain previous behavior you can add a "--no-switch" flag
which will keep you on your current branch. This way if somebody's legacy
script were to break it would be a simple matter of adding the switch,
rather than having to combine other commands to get the legacy behavior.

On Tue, Feb 7, 2017 at 1:19 AM, Andy Bradford 
wrote:

> 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
>
___
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"

[Richard Hipp]

On 2/7/17, Andy Bradford  wrote:
>
> Maybe this isn't even sufficient, but I do believe it's an improvement.
>

Here is a crazy, crazy thought:

Suppose we put lots and lots of extra text on many of the Fossil
commands, explaining
what just happened and the current repository state, after every
command.  Then provide a command like:

 fossil set newbie-hints off --global

That will turn off all the extra verbiage after users get comfortable
with the system.
-- 
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"

[Andy Bradford]

Thus said "Martin S. Weber" on Tue, 07 Feb 2017 11:07:55 +0100:

> thanks for proving my point.

You're welcome. I  never said branch names don't identify  a branch, nor
that they  are meaningless.  I said  that when  you use  ``fossil branch
new'' that  it doesn't imply that  the following commit will  be on that
branch.

And given the following:

> 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?).

Does not  Fossil allow  the use  of names for  most operations  and will
attempt to  resolve them  in a deterministic  fashion? Who  claimed that
they are worthless?

If I run ``fossil branch new'' it  creates a new branch according to the
BASIS that I gave it. It also outputs the artifact ID of the commit that
this tag was assigned  to (remember, a branch name is merely  a tag on a
commit, so one cannot have a tag without a commit).

I  agree,  however,  that  ``fossil  branch  new''  could  provide  more
information as to the state of the repository, and so:

http://www.fossil-scm.org/index.html/info/cbde195a118e231f

Which produces output like:

$ ./fossil branch new test 3f9a077a8d85d6bf5690f93ea561d6ee10c46024
New branch: c63492a121dd8af63e05924dfa4563a79fbae367
uuid: 3f9a077a8d85d6bf5690f93ea561d6ee10c46024 2017-02-07 14:57:22 UTC
child:c63492a121dd8af63e05924dfa4563a79fbae367 2017-02-07 14:57:56 UTC
tags: trunk
comment:  initial empty check-in (user: amb)

Maybe this isn't even sufficient, but I do believe it's an improvement.

Andy
-- 
TAI64 timestamp: 40005899e0dc


___
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"

[Martin S. Weber]

On 2017-02-06 23:17:00, Andy Bradford wrote:
> (...)
> Because it doesn't  matter what the name  of the branch is.  
> (continues to show examples where Andy, as the human, uses the branch-name to
> identify the branch)

thanks for proving my point.

Regards,
-Martin
___
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"

[Andy Bradford]

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"

[Andy Bradford]

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"

[Andy Bradford]

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] Bug in "fossil branch new"

[Warren Young]

On Feb 6, 2017, at 9:18 AM, Richard Hipp  wrote:
> 
> 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] Bug in "fossil branch new"

[Tony Papadimitriou]

+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 Hipp <d...@sqlite.org> 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"

[john lunzer]

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 Boogie 
wrote:

> 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"

[jungle Boogie]

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

Re: [fossil-users] Bug in "fossil branch new"

[Richard Hipp]

On 2/6/17, john lunzer  wrote:
> 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"

[Richard Hipp]

On 2/6/17, john lunzer  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=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"

[john lunzer]

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 lunzer  wrote:

> 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"

[john lunzer]

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"

[john lunzer]

On Mon, Feb 6, 2017 at 11:13 AM, Richard Hipp  wrote:

>
> >
> > 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"

[Richard Hipp]

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

Re: [fossil-users] Bug in "fossil branch new"

[Martin S. Weber]

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"

[bch]

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"

[Richard Hipp]

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

Re: [fossil-users] Bug in "fossil branch new"

[Richard Hipp]

On 2/5/17, john lunzer  wrote:
> 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