Re: vendor branches: small mistake in docs

Understood, and you're right, It's a bit unclear:

"We quite literally copy new files on top of existing files, *perhaps
exploding the libcomplex 1.1 release tarball atop our existing files
and directories*.
The goal here is to make our current directory contain *only* the
libcomplex 1.1 code, and to ensure that all that code is under
version control"

(emphasis mine)

The example they give doesn't meet the the stated goal. :-)

-- 
-- Tom Mornini
On Dec 20, 2005, at 4:31 PM, Adam Monsen wrote:
> Hi Tom,
>
> Thanks for your comments. First of all, I concur with your comments  
> on how to properly use vendor branches. My thoughts are just on  
> improving the example given in the docs.
>
>
> On 12/20/05, Tom Mornini wrote:
> I think you're assuming an overlay sort of replacement.
>
> Yes, this is what the previous paragraph suggests for this example:  
> Quoted: "We quite literally copy new files on top of existing  
> files, perhaps exploding the libcomplex 1.1 release tarball atop  
> our existing files and directories."
>
> No mention of deleting files. Yes, the very-userful  
> svn_load_dirs.pl is mentioned later, but I still believe the docs  
> could be ever so slightly improved.
>
> If the files are literally replaced, there could well be some  
> missing files.
>
> You'd have to remove all 1.0 files in the WC (avoiding .svn  
> directories)
> and then overlay the 1.1.
>
> You wouldn't want to remove  *all* code in the trunk, that would  
> wipe out your customizations to the libcomplex code.
>
> svn_load_dirs.pl or svk make this much easier.
>
> Agreed.
>
> -- 
> -- Tom Mornini
>
> On Dec 20, 2005, at 2:49 PM, Adam Monsen wrote:
>
>> From http://svnbook.red-bean.com/en/1.1/ch07s05.html ...
>> "After replacing the 1.0 code with 1.1 code, svn status will show  
>> files with local modifications as well as, perhaps, some  
>> unversioned or missing files."
>>
>> While unversioned files may exist, there will be no missing files.
>>
>> -- 
>> Adam Monsen
>> http://adammonsen.com/blog/
>
>
>
>
>
> -- 
> Adam Monsen
> http://adammonsen.com/blog/