Repository referencing in command lines (was Re: 08:16 < abentley> Better phrasing: [...])

[John A Meinel]

Matthew D. Fuller wrote:
> [ This mail developed along different directions than I'd originally
>    intended.  My main ideas are all in the second half, but a few
>    points along the way led to them.  I could spend an hour or two
>    trying to edit it all into a more coherent missive, or I can just
>    send it now.  I'm lazy. ]
> 
> On Thu, Feb 09, 2006 at 11:20:34PM +0100 I heard the voice of
> Erik B?gfors, and lo! it spake thus:
>> I think we should support paths in the repos, just like svn for
>> example, so you can have
>> REPODIR/trunk
>> REPODIR/branches/0.9
>> etc....
> 
> Please, no.  That's high on the list of reasons I skipped SVN
> altogether.
> 

I think the way bzr will support this sort of thing is very different
from how svn supports it. But right now that is exactly how we are
planning on doing it. A branch will have a url, which defines what it
is. I think the biggest problem with SVN is that they mix their working
trees with their branch paths. By removing the working tree from the
repository, you can do nice things like:

$REPO/
  bzr/ <- this is the release branch
   bugfixes/
   dev/
     mbp/ <- Martin's development branch
     jam/ <- My integration branch

Then to access a branch you have simply:

bzr get $REPO/bzr/dev/jam/

rather than
bzr get $REPO/bzr/ --branch=dev-jam

There has also been discussion of using URL parameters, (which just
means you use a semicolon to separate the sections) though that was more
discussed as a way of getting at a specific revision, more than a
specific branch.

Right now, a URL (semi-)uniquely defines a branch. It is a nice
property, that would be nice to keep with repositories.

I can also browse to http://$REPO/bzr/dev/jam/ and see that there is a
.bzr directory there. If you hide branches internally, then you can't do
that.


> 
>> * Creating a new standalone branch
>> * Creating a new branch in a repo
> 
> To me, these are the same thing; in both cases, you're creating a
> branch with nothing in it (until you add).  Where the branch is stored
> is kinda a side issue.  You've them both as just slightly different
> invocations to "bzr init"; I'd be tempted to make the repo-variant a
> flag; something like "bzr init --repo=/foo/bar" instead.
> 
> Of course, in a standalone branch, you don't have to call it anything;
> you can just `bzr nick` later if you want.  In a repository, you have
> to declare what the branch will be called.  I'd be tempted to add an
> arg and have "bzr init <location> <branch-name>"; maybe it's optional
> for standalone to declare the name, but it would be required for repo.
> 
> 
> As a side point, I'd also push heavily for a $BZR_REPO or such
> environmental variable.  I have a dozen or so wrapper scripts for CVS
> that call it with different $CVSROOT's for all the places I do work;
> that's a lot nicer than writing it on command lines, or trying to
> write wrapper scripts that substitute things in the middle of the
> line.  So something like "env BZR_REPO=foo/bar bzr init --repo" should
> work too.  See additional mentions below.
> 

The biggest problem with $BZR_REPO is the difficulty in saying "bzr get
path/foo" are you saying that you want the local directory path/foo, or
are you saying you want $BZR_REPO/path/foo.

We have discussed it, because it would be nice to have shorter paths for
things. I think we came to the idea that aliases would be a better
solution, since it handles more cases anyway.

So you would end up with:

bzr get ^jam/foo
bzr get ^home/foo
bzr get ^work/foo

(The alias syntax hasn't been defined, but Aaron's FAI used '^', which
was nicely distinct from other usage).

> 
>> * Creating a standalone branch based on another
>> * Creating a branch based on another branch and store in repo
> 
> These, as well, are the same.  But these show more the need for syntax
> in-line, rather than an argument.
> 
> I think this is the best question to tackle here.  The question needs
> to be "How do we denominate a branch in a repository"?
> 
> SVN does this by the path names.  I really, really hate that, as far
> as it's reflected in the actual structure of the repository.  Think of
> the effects on revnos and `bzr log`.  As a UI abstraction, I just
> single-really hate it.  So, I'd out that.

I would like to hear more about your thoughts. Since this was what we
had planned. And I don't fully understand your comments, to be able to
decide whether I agree or not.


...

> - Non-URL separated values.  "bzr branch repo:/foo/bar:mybranch"  This
>   recalls the $CVSROOT constructions like :ext:me at some.server:/foo/bar
>   in using the :'s to separate pieces of a single string.  This makes
>   it pretty easy to reference repo or standalone branches with very
>   similar syntax, and to declare branch names within the repo.

This is very similar to URL parameters, though I think they use ';'
instead of ':'. (So you have to escape it from a shell prompt).

[... discussion of how to use env variable]

Where do you need an environment variable, rather than having some other
method to define what you are working on.
Meaning, how do you determine what your current state is, and what is
your use case? If we allowed you to create a glob expression, that would
set your default repository based on path, would that give you what you
want? (So stuff in ~/dev/work would use a different repository than
~/dev/home).

I think we can do this in a way that people don't have to write 20
different shell aliases to get it to work how they want. Though maybe we
can try and support the shell aliases, since obviously someone like you
is comfortable with that method.

> 
> I think determining how we'll refer to a repository and a branch in
> it, in such a way that it can be described inline without piling on a
> bunch of --options, is the most necessary step in determining what
> commands will do what how.  Piling up a --repo=/my/repo and
> --branch-in-repo=mybranch is nasty, and it just gets double nasty in
> commands like 'branch' where we need to specify TWO branches, either
> of which can be repo/standalone.
> 
> 

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060210/49755f6e/attachment.pgp