right way to reverse engineer a "virgin" branch?

Chris Hecker checker at d6.com
Fri Apr 22 16:44:33 UTC 2011


Interesting trick!  But, sadly:

> As long as your branch contains a pristine copy of mediawiki-1.15.5
> somewhere in its mainline history,

This is not true for either site, since they were already working sites 
before I had them in bzr.

So, given that sadness, what's the best route?  Luckily, neither of them 
is too far from the pristine, so I think the core files will work out 
like I said (branch, maybe "branching" from the earlier closest point 
like you say, and then make sure site thinks it's virgin plus changes), 
but I don't know what to do about the extra files and directories from 
site in virgin?  Do I toast those, merge, and then remerge them from the 
past?

Thanks,
Chris



On 2011/04/21 23:46, Eric Siegerman wrote:
> On Thu, 2011-04-21 at 22:15 -0700, Chris Hecker wrote:
>> I have two websites, one on mediawiki, and one on wordpress, and I've
>> got them in bzr.  The problem is, because I'm dumb, I didn't start
> out
>> the branch with a virgin distribution branch from
>> wordpress.org/mediawiki.org, and then branch that to my site(s) [...]
>>
>> So, now I'd like to "unmerge" them, so to speak, so that updates from
>> the original code are easier.  What's the best way to do this?
>>
>> I have [one of the sites] at mediawiki-1.15.5, and I
>> want to update it to 1.16.4.
>
> As long as your branch contains a pristine copy of
> mediawiki-1.15.5 somewhere in its mainline history, setting this
> up will be a lot easier than you think.  (And a lot easier than
> my description suggests...)
>
> Definitions:
>    - $my_wiki: The branch containing both a pristine 1.15.5 and
>      your subsequent local changes
>    - $pristine_rev: the revision containing that pristine 1.15.5
>    - $upstream: the name of the new branch you want to create;
>      this is the one that will contain only pristine MediaWiki
>      distributions.
>
> Here's what to do:
>
> First, back up $my_wiki!
>
> Then:
>      $ bzr branch -r$pristine_rev $my_wiki $upstream
> That creates $upstream as a branch of $my_wiki, but ensuring that
> the latest revision in $upstream is a pristine copy of
> mediawiki-1.15.5.
>
>      $ cd $my_wiki
>      $ bzr missing --line
>
> That should report that $my_wiki contains extra revisions, i.e.
> the ones containing all your local changes since 1.15.5.  It
> should *not* report $upstream as containing any extra revisions.
>
> Now make $upstream forget that it was branched from $my_wiki:
>      $ vim $upstream/.bzr/branch/branch.conf
>      # delete the "parent_location=" line
>
> The next step is to tell $my_wiki that it's a child of $upstream:
>      $ vim $my_wiki/.bzr/branch/branch.conf
>      # add a "parent_location=" line; the value should be
>      # the location of $upstream.  (It can be either a URL
>      # or a relative pathname.)
>
> If all has gone well, you're now in the state you wanted:
>    - the newest revision in $upstream is a pristine
>      mediawiki-1.15.5
>
>    - $my_wiki contains that (not just that content, but that exact
>      Bazaar revision) plus your subsequent local changes
>
>    - $my_wiki thinks it was branched from $upstream (though in
>      fact it was the other way around)
>
> That means that at this point, after updating $upstream to
> MediaWiki 1.16.4, you can bring the changes into $my_wiki using a
> normal merge:
>
>      $ cd $my_wiki
>      $ bzr merge
>
>
>> What do I do about stuff that I don't want in the virgin branch, but
> do
>> in site?
>
> You won't have that specific situation, because $upstream doesn't
> contain *any* local files, but you might well have a similar
> problem: files in MediaWiki 1.15.5 that are no longer present in
> 1.16.4.  The easiest solution is to clear out the old release
> before importing the new one:
>      $ cd $upstream
>
>      # Get rid of everything except .bzr
>      $ rm -r *   # [sic]
>      $ ls -a
>      # rm any hidden "." files (other than .bzr of course)
>
> Now:
>    - untar the new distribution into $upstream
>    - "bzr mv --after" any files that were renamed upstream
>    - "bzr add" any remaining untracked files
>
> By deleting *all* of the working files before you unpacked the
> tarball, by definition you deleted any files that aren't in the
> new release :-), and so they won't be there to clutter things up.
>
> At this point, you can commit the new release, then merge it into
> $my_wiki.
>
>    - Eric
>
>
>
>



More information about the bazaar mailing list