On 03/07/2018 07:11 PM, Ben Franksen wrote:
> If we choose to add in-repo branches to Darcs, we do /not/ need to be
> concerned with branch identifiers! It is enough to able to name patches
> to uniquely identify a branch. It doesn't even have to be the top-most
> patch, just any patch in the initial segment of a branch. I think this
> will result in a UI that is at least as easy to use as that of Mercurial
> and still consistent and efficient as with git.
>
> We can and should allow to attach symbolic "human readable" names to
> branches, but they will have no fundamental relevance. It's a bit like
> using 'darcs pull -p patchname', you can use it and it is convenient but
> if in doubt there is always the hash to uniquely identify a single
> patch. A spontaneous idea I just had is this: if we add a feature to
> give symbolic names ("aliases") to patches, then these could double as
> branch names. We could maintain these associations in a simple text file
> with one line per alias and add a pref 'aliasfile' so we can keep the
> file under version control, quite similar to 'boringfile'.
Let me rephrase the conclusion: branches need not have a globally unique
identity. They are fully defined by the patches they contain, just like
separate clones of a repo.
The idea of using "patch aliases" as branch identifiers is a bit too
simple, though: a patch may at one point in time uniquely identify a
branch, but all sorts of operations can invalidate this property. So
this is not stable enough to be usable to identify branches.
Instead, we should attach a (human-readable) symbolic name to the head
inventory of the branch. This name should be purely local and not shared
with sibling repos (similar to branches in git). When we clone a repo,
we initialize the clone with an identical set of branch names but this
is just a copy.
Does this mean our UI will become as complicated as git's? I don't think
so. By default, branches should correspond to remote branches of the
same name in a 1:1 fashion.
For each branch we maintain the following data:
(1) the head inventory
(2) an (optional?) name
(3) an optional default repo
(4) an optional default branch
(5) a pristine tree
If there is no default repo for the current branch, we use the default
repo for the whole repo. If that does not exist either, and user hasn't
specified one we fail, same as we do now.
If we have a remote repo to work with but no explicit remote branch was
specified, we default the remote branch to be the same as the (name of
the) current branch.
If we have a remote repo and a remote branch (-name) to work with, but
the remote repo has no branch of this name, we fail. For instance:
> darcs pull http://my.project/ -b test
Sorry, remote repo has no branch named "test".
Use 'darcs show branches --repo=http://my.project/' to see which
branches are available.
A funny consequence of the design so far is that when you clone a (new
style, branched) repo without specifying a branch, you get a repo with
no working tree! Most commands in this repo should fail with a message
telling the user to first select a branch to work with, possibly listing
available branches, possibly telling them the command to use for that
('darcs checkout' as in git? Or rather 'darcs branch' as in Mercurial?
Should it be interactive by default?).
Compatibility
-------------
We can maintain full backward compatibility with repos created with
current and earlier Darcs versions by using the _darcs/format file. If
it misses a specific entry (say 'branches') we interact with the one
head inventory that it does have as if it were a branch.
We can maintain forward compatibility by choosing one of our branches to
be the default branch that old Darcs versions "see" as our only branch.
This is a local, per repo decision and is optional. I have considered to
use the current branch for this, but that would give remote users with
old Darcs versions a very strange experience: whenever we switch
branches, they think we have re-written the whole history (obliterated
patches, created new ones). If no default branch is set, attempts to
clone or pull the repo with old Darcs versions will fail with
copyFile:atomicCopyFileContents:withReplacementFile:copyFileToHandle:openBinaryFile:
does not exist (No such file or directory)
I think this is okay: remote users can complain that the repo "has
disappeared" or "is broken" and the nice repo maintainer can define a
default branch (or, if not so nice, tell them to upgrade their Darcs or
go to hell ;).
The default branch should be used *only* for compatibility. New Darcs
versions should not use it so as not to destroy the "all branches are
created equal" diction.
Open questions
--------------
(By no means a comprehensive list!)
Branches can be automatically created, so they may not have a name to
start with. It is not clear to me yet how (of if, at least by default)
they should be presented to the user. When such a branch gets created,
do we need to inform the user how to access this new branch? I think so,
because the user may not remember the identities of the patches it
consists of. Looks like we need to create names after all.
Branches can also "merge" with other branches. What exactly do I mean
with that? Well, branches can exchange patches, like repos, and I have
said in a previous post that patches common to two branches can and will
be commuted out to their common tail. If the last patch in the head
inventory of a branch is pulled into another branch, and vice versa,
then both branch names refer to the same inventory (namely their common
tail). Perhaps this is wrong, and we should represent such branches with
an /empty/ inventory, so we'd now have two empty inventories pointing to
the same (common) parent. This means we can no longer use patch
identifiers to identify branches. Is this a problem?
Deleting a branch should first of all delete the name. We may want to
keep the inventory and turn it into an anonymous branch, though.
Finally, irrecoverably deleting branches should perhaps be restricted to
a new subcommand of 'darcs optimize'. This command should ask for
confirmation for every single patch for which we remove the last
reference in this way.
Cheers
Ben
_______________________________________________
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users
