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: <unnamed>
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:     41b2cea47b0f23c6339222583f6cc9d07660ac8d 2017-02-06 17:01:56 UTC
tags:         dev
comment:      oy.dev (user: phaeton)
changes:      None. Already up-to-date
WARNING: multiple open leaf check-ins on dev:
  (1) 2017-02-06 17:01:56 [41b2cea47b] (current)
  (2) 2017-02-06 17:00:05 [e943565869]
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to