Converting subtree format to non-subtree format

[Harry Flink]

Hi Jelmer,

On Fri, October 1, 2010 13:39, Jelmer Vernooij wrote:
> On Fri, 2010-10-01 at 12:37 +0300, Harry Flink wrote:
>> What exactly do you mean by "didn't actually
>> use nested subtress". I mean, when I tried them
>> long time ago I used them for a while. Then I
>> removed them etc but of course cant get rid of
>> the revision history.
>>
>> I dont remember anymore if I did just "bzr rm"
>> or "bzr join" with the old subtrees to get rid
>> of them but I know there are no references to
>> any subtress anymore.
>>
>> So I actually used them - long time ago - but
>> not anymore. Can this still be a problem later?

> I would argue that in this case it really is a bug that you can pull
> your changes into a non-subtree repository. It should only be able to
> pull revisions without subtrees from a with-subtree format into a
> non-subtree format. And, similarly, it should be possible to run "bzr
> upgrade --2a" in a subtree format repository if you haven't used any
> actual subtrees.
>
>> What kind of issues are expected if any in my case?
>
> If you attempt to access the historical revisions that have the subtrees
> in them you might run into issues; I'm sure what specifically. My guess
> would be tracebacks when you e.g. try to use "bzr diff" on revisions
> that involve those subtrees.
>
> Cheers,
> jelmer


Seems like your conclusions are correct.
I can diff to older revision without problem
but doing...

# Revision 163 contains subtrees.
# This command works OK.
# Subtrees become as empty dirs as expected.
$ bzr revert -r163

# Diffing gives error
# Revision 165 contains also subtrees but
# same error comes when diffing this reverted
# repository to any other revision as well.
$ bzr diff -r165
bzr: ERROR: The method _generate_inventory is not supported on objects of
type CHKInventoryRepository.

Same goes with "bzr revert -r3000", after reverting
to old version with subtree, I cannot really
revert back to anywhere else.

Hmmm... I guess I should find some way to just
get rid of the subtrees in the revision history
up to revision 383.


>> On Thu, September 30, 2010 11:33, Marco Pantaleoni wrote:
>> > Good!
>> >
>> > Just be sure your old repos didn't actually
>> > use nested subtrees, otherwise you could
>> > experience problems later.
>> >
>> > Marco
>> >
>> > On Thu, Sep 30, 2010 at 9:58 AM, Harry Flink <
>> > to-harry-from-bzrmailinglist at steo.fi> wrote:
>> >
>> >> Thank you Marco!
>> >>
>> >> So simple solution and it works \o/.
>> >>
>> >> I havent tested it thoroughly yet but it
>> >> seems I have all the revision history
>> >> as should be and format is now "2a".
>> >>
>> >> I have only one repository... or I mean
>> >> branch, I havent used shared repositories
>> >> with the project but tested it long time
>> >> ago. Thus I dont need script, thanks.
>> >>
>> >> Also "bzr log" and "bzr log -v" seems
>> >> to be ALOT faster now than with old format.
>> >> With old format "bzr log <subdirectory>"
>> >> made bzr to crash but with new one I can
>> >> finally get list of history related to
>> >> a path.
>> >>
>> >> Thank you Marco again!
>> >>
>> >> Regards,
>> >> Harry Flink
>> >>
>> >>
>> >> On Thu, September 30, 2010 10:21, Marco Pantaleoni wrote:
>> >> > Hi Harry,
>> >> > if you are sure you are not actually using subtrees, you could be
>> able
>> >> to
>> >> > do:
>> >> >
>> >> > mv repo old-repo
>> >> > bzr init-repository --default-rich-root --no-trees repo
>> >> > (for each BRANCH in old-repo)
>> >> >   bzr init repo/BRANCH
>> >> >   bzr pull -d repo/BRANCH old-repo/BRANCH
>> >> >
>> >> > I also have a bash script that automates this for a large
>> collection
>> >> of
>> >> > repositories and branches, if you are interested.
>> >> >
>> >> > Marco
>> >> >
>> >> > P.S. I agree with you that users should be less involved in
>> repository
>> >> > format juggling (in an ideal world, at least).
>> >> >
>> >> > On Wed, Sep 29, 2010 at 10:51 PM, Harry Flink <
>> >> > to-harry-from-bzrmailinglist at steo.fi> wrote:
>> >> >
>> >> >> Hello!
>> >> >>
>> >> >>
>> >> >> Me and now many my co-workers are using
>> >> >> bazaar as main version control system and
>> >> >> really like it.
>> >> >>
>> >> >> I'm managing quite a big project with it and
>> >> >> over 2 years ago during jumping from SVN to BZR
>> >> >> tried the nested tree support which wasnt so
>> >> >> good idea. I got rid of the subtrees by just
>> >> >> "bzr rm" them and just keep all needed files
>> >> >> in the same big project. It seems to work OK.
>> >> >>
>> >> >> During the 2 years I have upgraded the BZR
>> >> >> directory format to newer formats but they
>> >> >> always have to be with subtree support.
>> >> >> (I dont get it why BZR users even have to
>> >> >> care about internal repository file formats?)
>> >> >>
>> >> >>
>> >> >> Now when branching my repo bzr (v2.1.1) gives
>> >> >> me the following warning:
>> >> >> "Fetching into experimental format RepositoryFormatKnitPack3().
>> >> >> This format may be unreliable or change in the future without an
>> >> upgrade
>> >> >> path."
>> >> >>
>> >> >>
>> >> >> Command "bzr info --verbose" shows the
>> >> >> following info about the repository format:
>> >> >>     control: Meta directory format 1
>> >> >> working tree: Working tree format 6
>> >> >>      branch: Branch format 6
>> >> >>  repository: Packs containing knits with subtree support
>> >> >>
>> >> >> I'm a bit worried for the support of this
>> >> >> respository format because I dont want to loose
>> >> >> my history of all 4000 revisions and still want
>> >> >> to keep up with latest versions of bzr.
>> >> >>
>> >> >>
>> >> >> Is there any kind of method to drop history
>> >> >> of subtrees so that I could go back using the
>> >> >> "normal" repository formats instead?
>> >> >>
>> >> >> I was hoping for something like SVNs
>> >> >> "svnadmin dump" text format. I dont know if it
>> >> >> could be possible to use some rebase/merge stuff
>> >> >> to do this step by step with automated script
>> >> >> by recreating it on another repository but skip
>> >> >> the very old revisions that relate to subtrees.
>> >> >>
>> >> >> I know this is my own fault being so stupid
>> >> >> to test experimental features long time ago
>> >> >> and not understand that these tests might
>> >> >> affect long time in the future too.
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Best Regards,
>> >> >> Harry Flink
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Marco Pantaleoni
>> >> >
>> >>
>> >>
>> >> --
>> >> Best Regards,
>> >> Harry Flink
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Marco Pantaleoni
>> >
>>
>>
>
>


-- 
Best Regards,
Harry Flink