[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Exclude a directory from a copy.

From: Gavin Baumanis <gavinb_at_thespidernet.com>
Date: Fri, 24 Jun 2011 13:17:36 +1000

I am not sure if I am missing something or not...
Possibly just "this" user error....

I have created a test repo as a test bed for the reintegration step.
and created the following structure;
/trunk
/trunk/wanted
/trunk/unwanted
/branches

I then did a WC->WC copy;
svn copy trunk/ branches/myNewBranch

Committed the change
svn commit branches/myNewBranch -m'Blah'

deleted the unwanted directory
svn rm branches/myNewBranch/unwanted
svn commit branches/myNewBranch -m'Blah'

I then created a file in /branches/myNewBranch/fred.txt
added, committed it.

I then tried to merge my changes back;
cd trunk
svn update
svn merge --reintegrate file:///Users/gavin/svn/repos/myProject/branches/myNewBranch

and I got the following result;
A wanted/fred.txt
D unwanted

I tried with URL->URL copy - just to see if that made any difference - but it doesn't and upon reflection why would it?

(Though I do take onboard that using a URL->URL copy/delete does away with the physical copy/delete upon my WC - which is a big time saver - because the unwanted directory contains something like 50,000 tiny files - and that is a time consuming couple of operatiojns)

I also understand that unwanted is being deleted from trunk - because it is a difference between the branch and trunk at the time of the merge.

I can simply revert the delete before commit
svn revert trunk/unwanted
svn commit -m'reintegrated from myNewBranch_at_xx to trunk'

and everything is as I would want it to be..

Initially I thought I would check if there was some "little gem" to be used that would do it without me having to the extra work of manually;
* Deleting the unwanted directory from myNewBranch
* Reverting the delete in the trunk after reintegration.

The URL->URL copy does away with the requirement of having to wait for the copy, then deletion of thousands of small files that make up the unwanted directory's contents. - so that's a great step forward in efficiency right there!

Finally, I am fine with having to do it, myself... I just thought I would see if there was a better way (internal to svn - all in one / special) first.
You never know what gems are hiding in there - if you don't ask.

As always - a big thanks for the assistance....
Gavin "Beau" Baumanis

On 23/06/2011, at 10:48 PM, Daniel Shahaf wrote:

> Konstantin Kolinko wrote on Thu, Jun 23, 2011 at 11:48:46 +0400:
>> 2011/6/23 Gavin Baumanis <gavinb_at_thespidernet.com>:
>>> Hi there everyone,
>>>
>>> I am just wondering if there is a short-hand way of excluding a directory from a copy?
>>>
>>> I am wanting to create a branch from the trunk - but omit a specific directory from the copy as it contains about 1GB of binary data that are not required for the work that will be occurring in the branch.
>>>
>>> I can manually do it, by doing a WC->WC copy and then simply deleting the sub-directory that I don't need, prior to committing the branch.
>>> But I thought I would ask if there was a smarter and more efficient way to do it first.
>>
>> Copying 1 GB takes time...
>>
>> You can
>> 1) create URL -> URL copy,
>> then do "svn delete URL" as a separate commit
>> 2) do not delete the unneeded subdirectory, but either do "svn switch"
>> (should preserve unmodified data in place), or a sparse checkout
>>
>> I think that both action in 1) should be possible to do in one commit
>> using svnmucc program - but I have never used it.
>>
>
> svnmucc -m logmsg cp HEAD $U/trunk $U/branches/foo rm $U/branches/foo/subdir
>
> But actually I suggest to do it as you suggested, with 'svn rm URL' as
> a separate commit, which is then 'merge --record-only'ed to trunk.
> (assuming it's a branch intended for reintegration)
>
>> Best regards,
>> Konstantin Kolinko
Received on 2011-06-24 05:18:33 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.