confused by repositories
John A Meinel
john at arbash-meinel.com
Thu May 11 02:09:23 BST 2006
Jamie Wilkinson wrote:
> This one time, at band camp, John A Meinel wrote:
>> Jamie Wilkinson wrote:
>>> What are the paths to projects like within the repository, on your working
>>> repo and your public repo?
>> Because I came from standalone branches, I tend to do a lot of leaf
>> branches, but no parents. Meaning I would have:
>> project/ <= repository base
>> 0.7/ <= integration branch for version 0.7
>> 0.7-foo/ <= feature branch
>> 0.7-baz/ <= other feature branch
>> 0.7-jam/ <= my personal branch
>> #Nothing has been released here yet :)
>> And then my working directories looked like:
>> project/ <= Repository
>> dev-0.7/ <= working tree
>> dev-0.7-baz/ <= working tree
>> The big reason for that is just that the default 'nick' for a branch is
>> its last path segment. And 'dev-0.7-jam' is a little better than just
> Ok, so your repo is 'dev', you work within the repo with various named
> branches; That gets mirrored to the public repo? So if I wanted
> dev-0.7-jam I'd go:
> bzr get http://jam-server.example.org/prefix/dev/project/dev-0.7-jam
I tend to create a repository for each project. Because back with
weaves, doing a 'get' would copy over everything, (so getting project A
would pull the inventory weaves for project B. knits should be better
Actually the public location is:
bzr get http://bzr.arbash-meinel.com/mirrors/mifar/dev/0.7-jam/
And I have:
Where the repository stuff lives, and
Where the branch stuff exists
> I use a similar structure; *all* my source code lives in ~/src, and within
> that I have a bunch of directories for each project. Within them, I have
> actual working trees from CVS, Subversion, Arch, bzr, etc.:
> But of course it's not *all* bzr branches in there.
> If I were to make a repo elsewhere, and check out branches from it, how do I
> create a branch within the repo?
At present, you can only 'push' to create remote branches. In the
future, you should be able to 'bzr branch sftp:/a sftp:/b'
And maybe at some point locally branching a bound will create a remote
branch, and bind against it, but the UI for it hasn't been worked out.
> (This sounds like a silly question I guess, I should just RTFM. Probably
> I'm thinking of something similar to Aarons setup?)
So right now you have to do:
bzr branch dev-0.7-jam dev-0.7-feature
bzr push sftp://host/srv/bzr/public/mifar/dev/0.7-feature
bzr bind sftp://host/srv/bzr/public/mifar/dev/0.7-feature
>>> What happens if I'm offline? Do I need to manually unbind? If so, does the
>>> unbind only need to happen once?
>> Unbind breaks the binding, so you have to re-'bind' later.
> Sure, but do I need to unbind? If I commit locally and the push times out,
> will it just queue until the next commit when online, and that updates the
> public mirror?
If you commit --local, it doesn't try to push.
The next time you are online and you *commit* (or push) it will try to
push both commits to the public location.
>>> If so, do you automate your bind/unbind somehow? :-) (I'm terribly lazy :-)
>> However, bzr supports 'bzr commit --local' which lets you do a commit
>> just to the local tree.
> So you have to tell bzr not to push if you're offline? I guess it's an ok
> workaround but I'd prefer not to have to worry; muscle-memory and all that
> means I'm going to forget frequently...
>> Does that help?
> Yep, thanks.
We've discussed auto-ignore. The problem is making sure that timing out
is treated differently from permission denied, from out-of-date, etc.
Also, making sure that users realize that they haven't actually
published things. If bzr hides the fact that it is committing only
locally, you would be surprised when your changes weren't in the public
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060510/f68a0c60/attachment.pgp
More information about the bazaar