On Fri, Mar 14, 2014 at 10:55:23AM +0000, Rob Taylor wrote:
On 13/03/14 17:17, Richard Maw wrote:
>We want to create a new workspace. Now that workspaces and system
>branches have merged, there is no `morph init` command, so we just use
>`morph clone`.
>
> $ morph clone baserock:baserock/definitions
> Created new workspace in "baserock"
> $ ls
> baserock
> $ cd baserock
> $ ls -A
> .morph-system-branch
> definitions
I suspect most people will want to work on a feature branch. How
would this work?
See later discussion.
<snip>
> $ morph edit foundation/systemd.morph
> Checked-out "foundation/systemd.morph" at
"~/baserock/foundation/systemd"
> $ cd ../../foundation/systemd
> $ git branch
> * master/foundation/systemd
<snip>
I note this isn't too awful as in regular work flow, you don't need
to refer to this branch name, but it should be *comprehensible* as
users will need to see it and be able to find their branches, e.g.
when browsing a trove
See later discussion on how the branch names aren't sufficient in this scheme.
>*NOTE* This will un-share repositories in the case where they
also use
>the same ref (e.g. gcc in build-essential). We may want a scheme to
>share this.
>
>*NOTE* The HEAD of our definitions repository being `master` means that
>we can't push this branch since:
>
>1. Trove's Gitano rule-set prevents you pushing branches to repositories
> in upstream: that don't start with your trove prefix (e.g. baserock/)
>2. Git won't accept master/* as a valid ref, since master exists.
>
>Some suggested fixes are:
>1. Have the HEAD ref of definitions repository always start with your
> trove prefix.
>2. Prepend the trove prefix if it doesn't already start with it
>3. Fetch in upstream's refs in a different namespace and slacken
> Gitano's rule-set to allow pushing to branches that don't start with
> your trove prefix
The trove prefix was introduced to avoid branch name classes when
peering troves and so we could support a mesh of troves in the
future. Given this is still the case, I think when morph creates
branches it should create them in the trove prefix. At least unless
we can think of a better way to do this...
It could do the translation of branch namespaces at lorry time, so _you_
always see your branches in the root namespace, but if your trove lorries
from
git.baserock.org, it fetches those branches as baserock/*
I think <trove>/<branchname>{<chunkname>} may work
and make sense to
people, eg in this case baserock/master{foundation/systemd}. I've
tested this format out a bit and seems to work with relevant
services and core git.
I'm just a bit wary of using unusual characters in the branch name,
since your shell may interpret it specially, since there's no reason
you can't put a comma in your branch names.
Another option is to remove the complication and force all repos to
always build from the same ref, and if you want multiple refs for
the same repo, you duplicate the repo. However that could get a bit
annoying for things like linux vs linux-api-headers.
Either duplicate the repo, or build linux-api-headers from the same ref,
which means kernel tweaks involve rebuilding everything, even though
they're good about API compatibility.
>*NOTE* It's also possible that you have multiple morphologies
repositories
>on your trove. You could get a name conflict if two of them have a
>system branch of the same name, and edit the same chunk, which would
>be a surprising GOTCHA if you need to make the same change to multiple
>repositories (e.g. a security fix affecting a component in both systems).
>
>It would be possible to avoid this by requiring unique branch names, but
>for the security update case, this is an odd restriction that unreasonable
>to check, since you need to keep track of the locations of every
>morphologies repository.
I still think we need to incorporate the root repository name into the
branch, to avoid conflicts, since this was one of the ways we suggested
dealing with the definitions repository getting too large.
So I suggest we expand the repository alias, take the path part, and
prepend the branch name with that.
So baserock:baserock/morphs becomes
git://git.baserock.org/baserock/baserock/definitions, so our
repository prefix is baserock/baserock/definitions. Combined with
our branch name of master and our chunk of foundation/systemd, we
get `baserock/baserock/definitions/master/foundation/systemd`, or
`baserock/baserock/definitions/master{foundation/systemd}`, if we go
with that layout.
>`deprecated commands`
>---------------------
>
>`morph init` is now deprecated, since you don't create a workspace
>independently of the system branch any more.
>
>`morph checkout` became `morph clone`.
I would suggest that morphe checkout also becomes deprecated and all
the deprecated commands print a message indicating they are
depreceaded and directing you information on morph clone, possibly
with a 'maybe you meant this: <new command>'
Makes sense to me.
>`morph branch` no longer exists. We still need to specify a way
to create
>a new branch.
>
>The simplest thing to do would be to add a new option to `morph clone`
>to specify what we want to call the new branch.
>
yes, this. In fact I'd just have it as an optional second parameter,
and that second paramater defaults to troveid/master. Could also be
non optional.
So you are suggesting the following?:
morph clone $repo # clone and check-out HEAD
morph clone $repo $ref # clone and check-out existing $ref
morph clone $repo $newref $oldref # clone and check-out $oldref as $newref
If it's the same subcommand, we can't have an optional $oldref, since
then we'd have to disambiguate between "create new branch based off HEAD"
and "check out existing branch" by if it already exists, which would
have surprising behaviour.
This also prevents us being able to say "clone this repo from $repo and
rather than using the basename to determine the directory, put it in
this directory"
Optional, positional parameters here would lead to too much ambiguity
here, so I'd rather "check out from this ref" and "call our new branch
this" be option flags, since this way we're closer to the behaviour of
git, so there's less surprise.
How often would people actually want to check out master rather than
creating a feature branch?
I often just want to build an existing system, so checkout master
regularly.
Also, to aid understanding, here is what our tree will look like after
the above commands:
~/
baserock/
.morph-system-branch/
definitions/
.git/
release.morph
base-system-x86_64-generic.morph
core/
morph
systemd.morph
...
...
core/
systemd/
.git
configure.ac
...