bzrtools- cbranch sets parent

[John Arbash Meinel]

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

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>> Aaron Bentley wrote:
>>>>> Perhaps it's full of all kinds of cruft because you don't rsync it ;-)
>>>>>
>>> Well, when I say cruft, I mean that I have all my working trees, etc in
>>> there.
> 
> That's what I figured.  My checkouts are not in my repo.  In fact, my
> repo's on an NFS mount.
> 
>>> 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.
> 
> Me too.  The main thing is to avoid mixing publicly redistributable code
> with proprietary code.

Sure. I do have a fully private shared repository and a few public ones.
Like my personal bzr branches are in a separate repo from my mirrors of
other peoples branches.
I've thought about merging them, but it is just easier to leave it with
my current directory layout.
(Theoretically, just doing a symlink for the .bzr directory would share
everything, but I still would need to be careful that the contents of
all branches were pulled across first.)

> 
>>> 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.
> 
> I would operate it on a per-branch basis, rather than per-head.  I don't
> see the need to provide revisions that aren't present in any branch.

Well, the idea of 'per head' is that you guarantee not to lose anything,
even if you accidentally deleted a branch. However, I think per-branch
is a better starting point.

> 
>>> 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.
> 
> In a 'nuclear launch codes' scenario, I think it would be bad if we made
> it look like the revisions were deleted, when in fact, they weren't.

Well, we already do that, since if there is a cancel during push, we may
have written text to the .knit file, but not updated the .kndx. Or we
could have updated *part* of the .kndx, but didn't finish writing out a
record.

Or we could have pulled the texts, but stopped before the inventory or
revision entry was written.

So if we really want nuke, we need to extract the contents of all the
.knit files and check for revision ids that we don't want. (a .knit hunk
starts with a version id marker and sha1 sum, and finishes with an 'end
version id' marker, so while you would lose the ancestry, which loses
who the delta is against, if you have the 'revision' entry, you can
regenerate everything).

So a precursor to 'nuke' would just be 'hide'. Since nuke has a lot more
work to do.

> 
> To return to the cbranch-sets-parent thing:
> Is cbranch the right place for this?  Shouldn't checkout be setting the
> parent to be the same as the checked-out branch's parent?  This the
> behaviour you get with lightweight checkouts.
> 
> Aaron

Well, there are a few things going on here.

1) The first thing 'cbranch' does is 'bzr branch local sftp://remote'
This wasn't possible before my encoding branch landed, but it is now.
Which means that we are setting a local file:/// url as the parent for a
remote branch. And I don't think we should be doing that.
(When we are about to set_parent(), we should check if source is local
and dest is not, then don't set the parent).

2) We've discussed in the past that a bound branch should actually use
the master's parent location, rather than its own. That makes
heavyweight act more like a lightweight. This still doesn't help my
situation though, because if we fix (1), then the remote location
doesn't have a parent.
(A lightweight checkout doesn't have a local parent, it is forced to use
the remote branch parent).

So while right now it would technically work, if we fix the other bugs,
then it would break.

So for *my* use case, cbranch should set the parent.

I'll file a bug for (1).

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEwSecJdeBCYSNAAMRAlsiAKCuM6vsktVbyRGZ5MevrgAr47lZaQCfc3OA
pdntYaINZMkJPE9wcxkBkvE=
=/kSu
-----END PGP SIGNATURE-----