right way to reverse engineer a "virgin" branch?

[Chris Hecker]

Okay, it looks like deleting the files in virgin, merging virgin into 
site, checking in, and then merging the files back into site from the 
previous revision isn't going to work.  bzr doubled the size of my 
repository.

Hmm, maybe I'll rebranch and see if it's just temporary stuff and it 
still knows they're the same files.  Log seems to track the history.  If 
not, then this technique isn't going to work for me, I can't double the 
repo size.

Is there a way to selectively reject parts of a merge?  So, if I delete 
images/* in virgin, and then merge version -> site, can I accept the 
merge as done, but not lose the files?

Chris


On 2011/04/22 09:44, Chris Hecker wrote:
>
> 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
>>
>>
>>
>>