bzrtools- cbranch sets parent

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>>>> With my setup, cbranch only affects my local repo, but my public repo is
>>>>> a mirror of my local repo.
>>>
>>> As in you do an 'rsync' to mirror it? I think that is the big difference
>>> between us. I would not use rsync to mirror my local repo, because it
>>> *is* full of all kinds of cruft.
> 
> Perhaps it's full of all kinds of cruft because you don't rsync it ;-)
> 
> I find using rsync is a pretty nice tradeoff:
> 1. One command pushes all my branches
> 2. Commit is fast

Well, when I say cruft, I mean that I have all my working trees, etc in
there.
But I also probably have some plugin revisions leaking into my bzr
repository, etc.

At one point I was more careful not to mix my repositories, but since
push, pull and branch have been fixed to only copy the ancestry and not
the whole repository, I don't worry about it as much anymore.

But I also have to be more careful that I either push or use checkouts,
since there isn't a simple command (yet) that makes sure all the local
revisions have been pushed to the public location.

> 
> You get more scenarios where public repo == private repo when you've got
> group development and stuff is being shared over NFS/SMB, or when
> someone's running a web server on their devel machine.
> 
>>> But thankfully, bzr handles pushing just what I want. And, it means I
>>> can do this on lots of machines, and have them all feed into the same
>>> location.
> 
> That *is* an advantage.
> 
> Aaron

I think it might be worthwhile to have some sort of 'mirror repository'
command. Coupled with 'heads' it would mean that you could guarantee you
can get back any committed revision.

Though I know I've started using uncommit more lately. Especially when
working on a simple feature fix, versus something more long lived.
(mostly motivated by the "don't commit broken code" thread, and the fact
that bundles can get a bit unwieldy if you have too much history).

So probably if I ran 'heads' on my repository, I would find lots of dead
ends. If 'heads' was ever a core command, I think people would start
clamoring for ways of really nuking entries. The short term fix would
just be to rewrite revisions.kndx leaving out the sections you don't
want. It still is just hiding the revisions, but they would be hidden
from 'heads' at least.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEwRaYJdeBCYSNAAMRAlXeAKDQcN+WjJV6W+1h6vAo1hFQQyDNagCdGFwL
BfdENqU9G2Jko9CKgNLwA8E=
=iEOY
-----END PGP SIGNATURE-----