right way to reverse engineer a "virgin" branch?

[Chris Hecker]

Nope, a fresh branch into a fresh repo is a bit smaller, but it's still 
clearly duplicating all of the files (466mb of them).  I need another 
way to do this.

I guess I will mess around with revert instead of merge to get the files 
back.  Hopefully somebody knows a) whether what I want to do is 
possible, and b) how to do it.

To reiterate for clarity, I have two branches:

site
virgin

virgin is branched off site since only site existed for a while, but 
going forward, I will put new code into virgin, then merge it into site 
so that site retains its changes and virgin is a pristine copy of 
mediawiki at the current version.  Both have a big images/* directory 
due to the old branch from site->virgin.  virgin shouldn't have images/* 
  If I bzr rm images/* in virgin, then merge to site, it deletes the 
files in site, as you'd expect.  If I bzr merge -r n..n-1 then it 
recreates the files properly, yet it duplicates them in the repo, which 
is bad given that it's a lot of large files.

So, I want a way of getting rid of images/* in virgin, but not in site, 
but still being able to merge virgin->site in the future.

Hopefully that makes sense.

Chris


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