Repository referencing in command lines

[John A Meinel]

Matthew D. Fuller wrote:
> On Fri, Feb 10, 2006 at 09:04:59AM -0600 I heard the voice of
> John A Meinel, and lo! it spake thus:
>> $REPO/
>>   bzr/ <- this is the release branch
>>    bugfixes/
>>    dev/
>>      mbp/ <- Martin's development branch
>>      jam/ <- My integration branch
> 
> To be sure I understand, let me clarify myself on 3 properties of
> this:
> 
> 1) "bzr" in this sense is roughly equivalent to CVS's "modules".  (but
>    see below)
> 
> 2) All the sublevels are "equal" branches.  That is, "bugfixes/foo"
>    and "dev/bar" are treated just the same as if they were named
>    "bugfixes.foo" and "dev.bar".  The naming just provides a
>    conceptual hierarchy, it doesn't make 'higher' or 'lower'-level
>    branches, and "dev" is by itself not a branch; it's just a part of
>    a label.  (this isn't a very clear explanation of what I mean)
> 

I think I understand what you mean, and yes, we aren't planning on
defining what the branches mean, just giving users the ability to define
their own meanings.

> I can go with those.
> 
> 3) This is actually reflected in the physical layout of the
>    repository.  i.e., you'd have
>    $REPO/
>      .bzr/  (actual revision store)
>      bzr/
>        dev/  (branch-specific data for the "dev" branch of the "bzr"
>               module, referencing the revisions in the top-level .bzr)
> 
> That I hadn't considered quite so much.  Reflexively, I draw back from
> it a little bit, but I can't come up with a good reason why.  And it's
> sensible.  So I'll go with that.
> 
> 
> [On Modules, from above]
> 
> The alternative is not having a 'module' concept at all, that
> "$REPO/foo/bar" and "$REPO/baz/quuz" refer to branches in completely
> the same namespace.  I don't like that quite so much; if all the
> branches in a repository are "siblings", I'd personally create a
> separate repository for each 'project'.  If I can divide it into
> modules, each of which defines a namespace of branches within it, I
> can put a bunch of projects in one repo.
> 
> I don't s'pose it much _matters_ either way; I'd just tend to work
> with it differently depending.
> 

I'm not sure if I understand what you mean about 'siblings' versus
'modules'.

> 
>> Then to access a branch you have simply:
>>
>> bzr get $REPO/bzr/dev/jam/
>>
>> rather than
>> bzr get $REPO/bzr/ --branch=dev-jam
> 
> Roughly, I dislike this because it's harder to see by eye what the
> branch name is.  I mean, if I say
> "sftp://foo@bar/depot/repo/nix/run/shazaam", am I referring to a
> branch called "shazaam", or one called "run/shazaam", or...  I like it
> being obvious what's what.
> 
> In the full syntax in my other mail, I'd write that as
> 
> % bzr get repo:$REPO/bzr:dev/jam
> (or maybe repo:$REPO:bzr/dev/jam, depending on how we handle questions
> of modules, and how much of that path actually is the repository).
> 
> 
>> Right now, a URL (semi-)uniquely defines a branch. It is a nice
>> property, that would be nice to keep with repositories.
> 
> It does have advantages.
> 
> 
>> 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.
> 
> Well, that's easy; if you wanted the repo, you'd specify something
> like "bzr get repo::branch.name".  The theory is that if you somehow
> need a repo (which you wouldn't, unless you specified repo:[...]), the
> env variable would be used as the default.
> 
> I'm not quite wedded to that syntax, of course; the
> "repo::branch.name" form, omitting the repo path in the middle, IS a
> little ugly.
> 

The problem is we don't really have repo: syntax. We have URL syntax.
I'm pretty sure there are reasons why, if only because it is a fairly
unified syntax, rather than implementing another custom syntax for bzr.
(And it handles if bzr is working over sftp or http, etc).

> 
>> 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.
> 
> Aliases are certainly more flexible.  I shy away a little from using
> markers like ^ for them, since that breaks if you define paths with
> foolish characters in them; that's why I had a separate tag repoalias:
> (or whatever it was; I already forget ;) in my mention of them.  But
> yes; no matter what other shortcuts or tricks we get, I very much want
> to be able to use aliases in co and branch and merge and push and
> whatever else.
> 
> The primary use for the $CVSROOT variable in CVS is really for cases
> where, on one machine, you pretty much ALWAYS use a single repository.
> In the bzr case, that would make doing a 'bzr co' easy, since you
> don't have to specify the repo.  However, it doesn't gain you near as
> much on 'branch' and the like, since we have standalones.  So perhaps
> it's not quite as useful.
> 
> Still, it's handy for wrapping.  Aliases give you a lot more
> flexibility, but they require changing in the middle of the line,
> which is mentally harder for me than changing at the beginning.  I
> have the script wrappers partly because it saves typing long paths,
> but also because it's easier for me to switch from
> 
>     % foocvs co
>   to
>     % barcvs co
> 
>   than it would be to go from
> 
>     % cvs -d^foo co
>   to
>     % cvs -d^bar co
> 
> Not because of the length; just the location within the line.  It's
> easier for me mentally to change the beginning or end, than the middle
> (and it's easier from the shell, with ^A/^E, too).  Maybe I'm just
> weird, and that doesn't matter to anybody else, though.
> 
> 
> "branch" is a good example of why I like the env variable over the
> alias.  It takes basically two branch descriptions; one to branch
> from, the other to branch to.  And either (or both, or neither)
> _could_ refer to a repo branch.  If I have a wrapper that sets an env
> variable for the repository in question, I can do "abcbzr branch foo
> repo::" or "abcbzr branch repo::foo", and it'll pull from/to the
> "right" repository.  If that had to be done via aliases, it would mean
> the script trying to parse out my command line to figure out where to
> insert the alias, which is much harder and more error-prone.
> 
> 
>>> 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.
> 
> Well, as above, I _really_ hate how SVN jams all that stuff into the
> file layout namespace (see para below).  That doesn't really affect bzr
> though.
> 
> I guess mostly, I dislike the inability to see exactly what the name
> of the branch is in the URL.  It feels like "what branch this is" is a
> separate piece of information from "where the branch is", and jamming
> them together does a big thud for me.
> 
> [ On 'file layout']  I'm having trouble coming up with a good way to
> phrase exactly what I mean by that.  The closest I can get is "the
> layout of files in the project", vs. "the layout of files in the
> repository".  In SVN, the former includes all these directories that
> are meant to describe branches, even though you probably wouldn't
> often checkout from the 'top level', but rather from deeper in the
> tree.  That's a pretty murky explanation too, isn't it.  Blah.  But
> it's perfectly clear in my head what I mean, so if you'll all just
> tune your brains to 378.4GHz...
> 

My transponder only goes to 375GHz unfortunately. :)

I think my problem with SVN is that it mixes the working tree files with
the branch names. I don't have as big of a problem with 'what the branch
is' versus 'where the branch is'.

I think it is a natural punning. And prevents the "the branch is at
'foo', but it actually is the 'bar' branch."

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/eb23aa4e/attachment.pgp