'bzr join' losing revisions?

JP Vossen jp at jpsdomain.org
Sat Jan 25 00:50:15 UTC 2014


Short version:  Solved...  Jelmer was right, of course (and thank you!), 
and that showed me I didn't really want to do it that way anyway.  So I 
found a different way, detailed below for the record.

On 01/23/2014 07:26 AM, Jelmer Vernooij wrote:
> On Thu, Jan 23, 2014 at 04:30:27AM -0500, JP Vossen wrote:
>> I have a directory structure (tree (format: 2a)) like:
>> 	top			# revno 741	# shared repository: .
>> 		repo1		# revno 825	# shared repository: top
>> 		repo2		# revno 809	# shared repository: top
>>
>> Both repo1 and repo2 were originally in top, but I broke them out
>> using 'bzr split'.  Now I need to move some code (and revisions and
>> history) from repo1 to repo2.  What I think I want to do at a high
>> level is:
>> 	bzr join repo1 and repo2 && bzr ci
>> 	bzr mv repo1/some/code /repo2/elsewhere && bzr ci
>> 	bzr split repo1 and repo2 && bzr ci
>>
>> But when I do this:
>> 	cd top
>> 	bzr join repo1
>> 	bzr join repo2
>> 	bzr ci
>>
>> All 3 locations go to revno 742 and as far as I can see I just lose
>> the 741+ stuff in repo1&2!  (I'm working with copies and have
>> backups and all that, so the only problem is that I can't do what I
>> want...)

> If you run "bzr log -n0" to display merged revisions, that should show
> you the history of repo1 and repo2. By default, "bzr log" does not
> show merged revisions.

I should have noted that I am using 'bzr revno' to get those head revisions.

> Alternatively, try a tool like "bzr qlog".

And I should have noted that is what I'm using to eyeball the 
differences.  (Awesome cross-platform GUI tools are one reason I prefer 
bzr to git.  Even though I'm  a CLI guy, you simply can't beat a 
colorized side-by-side GUI diff/merge tool.  Meld is great too.)

But you are 100% correct, I was simply not seeing the "plus in the 
circle" indication of the merge (my work-flow doesn't really merge at 
all so I'm not used to looking for that).  It is all there, but I lose 
the human readable revnos I've documented in my status reports.  :-/ 
Ha, it gave me what I asked for but it isn't what I want...  :-)


So maybe I should step back to the top and ask: how can I move 
code/history from BZR repo1 to repo2?  And it turns out, doing a few 
'bzr fast-export | bzr fast-import-filter' then some selective 'bzr 
fast-import' operations works out better.

That gets the code and history moved without disrupting *most* of the 
revnos I've documented.  The stuff I'm merging in does get changed 
revnos, but I can live with that.  (Human-readable revnos are another 
reason I prefer bzr over git, even when they occasionally cause an 
"issue" like this...)

The lack of wildcards or regular expressions for fast-import-filter was 
a bit tedious, and I found the 'fast-import --directory' option didn't 
do what I wanted/expected, but that's nothing a 'bzr mv' can't fix.

My example at top was simplified, I actually had 1 dir to move into 3 
sections in 3 places in 2 different other repos.  So for the record, at 
a high level my solution was more-or-less as follows.

### Get all of "some/code"
cd /tmp
bzr fast-export ~/top/repo1 \
   | bzr fast-import-filter --include_paths='some/code' \
   > /tmp/some-code.fi
bzr fast-import /tmp/some-code.fi TEMP_some-code

### Break that up into more/smaller pieces x3, only 1 shown
bzr fast-export TEMP_some-code \
   | bzr fast-import-filter --include_paths='this-that' \
   > /tmp/some-code-this-that.fi
bzr fast-import /tmp/some-code-this-that.fi TEMP_this-that

### Merge it in x3, only 1 shown
cd ~/top/repo2
bzr merge --force -r0..-1 /tmp/TEMP_this_that
bzr mv this_that/something elsewhere
bzr ci -m'MIGRATED some code from here to there'

Thanks,
JP
----------------------------|:::======|-------------------------------
JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
My Account, My Opinions     |=========|      http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.



More information about the bazaar mailing list