[RFC] Morph branch-from-image

Sam Thursfield sam.thursfield at codethink.co.uk
Tue Jan 29 12:44:32 GMT 2013

On 01/29/2013 12:11 PM, Richard Maw wrote:
> On Tue, Jan 29, 2013 at 11:28:30AM +0000, Sam Thursfield wrote:
>> Hi
>> On 01/28/2013 04:18 PM, Richard Maw wrote:
>>> The basic behaviour of given an image, create a System Branch petrified
>>> at the point where it was built is well specified, but I still have some
>>> further questions about how it should work before I get too tied to an
>>> implementation which may turn out to be wrong.
>>> 1. How should the baserock metadata be given.
>>>     a. Path to Disk image
>>>        branch-from-image mounts it to find the metadata.
>>>     b. Path to directory
>>>        branch-from-image globs for metadata in the directory
>>>     c. List of paths to metadata files
>>>        branch-from-image leaves finding metadata up to caller
>> Initially I pictured this command being run on the image itself (ie.
>> get the source code for the actual system you're running), in which
>> case you don't need to provide any parameters. Supporting both that
>> case (no parameters) and getting source for a different system image
>> (pass the path to the system image) seems like all we need.
> Ah, so the path to directory option, but defaulting to /baserock, good
> idea.

I was thinking the path to the image itself, actually. The metadata in 
/baserock will always be inside the disk image, so if we require a path 
to a metadata directory when the user wants to check out the code for a 
non-running image, we're making them loopback-mount the disk image 
manually before they run the command every time.


>>> 3. Does the caller specify the branch's root repository and name?
>>>     The branch the System was built from and its repository is stored
>>>     in the metadata, but if it doesn't exist any more, it will need a
>>>     fallback anyway.
>>>     Specifying gives it a nice symmetry with `morph branch` which
>>>     defaults to branching from master, but can be told a different
>>>     branch instead. With it given you're saying branch as this but from
>>>     this image instead of master.
>> It seems that in the .meta files we store the full URLs rather than
>> the keyed URLs of the git repos. That's a good thing (otherwise
>> different repo-alias configs would make everyone confused, all the
>> time). However, if we're checking out a system branch which someone
>> is going to do a lot of work on (if all they want to do is go "what
>> code am I running" maybe this doesn't matter) we really want to
>> restore the repo aliases so that git://git.baserock.org/baserock
>> becomes baserock: etc.
>> Perhaps it's finally time to write the code to do this :)
> That's a different issue to the one described, though it is addressed
> later. This is more about what the branch should be called and where is
> its root repository.
> This could be the same as it was built from, but you may not want it
> to be, and the branch may no longer exist.

If the root repository no longer exists, I think the user gets to keep 
all of the pieces. For the branch name, I'm starting to think that we 
should let the user specify it. /etc/os-release can tell them the branch 
the system was originally built from so they can specify the same branch 
name if they want.

>>> 5. When should it give up trying to make the branch?
>>>     a. When the commit the System was built from does not exist?
>>>     b. When the branch the System was built from does not have a similar
>>>        commit?
>>>        This could be expensive to work out and probably not worth the
>>>        work.
>>>     c. When the branch does not exist at all?
>>>        At this point the morphologies can be regenerated from the
>>>        metadata, but it's going to be complicated.
>> If we're using a feature branch workflow, it'll be possible for the
>> branch to have been deleted but the commits themselves to have been
>> merged into a different branch. So I think we should mainly try to
>> honour the SHA1s.
>> Have you come up with actual usage scenarios for this yet?
> Rob Taylor's suggestion yesterday was that it's for the case of:
> 1. You have a problem with your system.
> 2. You branch from the System.
> 3. You fix the bug in your branch.
> 4. You send the patch upstream.
> My thoughts have been revolving around the use case of needing to
> reproduce a build, at which point it's just branch it then build again.
> This could be required if you broke your system, but you still have
> access to /baserock

In the first case the user wants their own personal branch name; in the 
second case they might want to reuse the original branch name or a 
personal variant. I'm starting to think we should always allow the user 
to specify the branch name (and you're right, it does create a nice 
symmetry with 'morph branch')

>> I think that would help us decide whether it's more useful to guess a
>> branch name by following parent commits until we get to a ref,
> This wouldn't work, since the tip of the branch has the ref, and
> following parents leads to the root.
> I think you'd have to start from all the tips, and work out which branch
> has the shortest distance to the commit.

That doesn't sound fun at all.

>>> 8. Should morph attempt to convert expanded repository urls back to
>>>    their aliases?
>>>    The metadata only contains the expanded urls, it's possible to work
>>>    backwards using your repo aliases, but given how flexible the aliases
>>>    are, it's strictly a search of all possible substrings of the
>>>    repository url passed to every known repo-alias.
>> Yes :) It would make some system-branch commands more user friendly
>> too if we had code to do this.
> One problem with this is that your repo-aliases may not be the same as
> they were when the image was built, so getting back to the originals may
> not be possible, and it could take a while to find this out.

I don't think that this would be a problem in the real world. Changing 
baserock: is not something we want to do often. (I'd like to change it, 
so that I stop having to write baserock:baserock/morphs everywhere, but 
that's beside the point).

I don't think it would be slow, either. I have 5 repo aliases in my 
morph.conf currently, so 10 possible patterns to match a candidate URL 


More information about the baserock-dev mailing list