Re: TortoiseSVN error

[Stefan Sperling]

On Tue, Jun 21, 2011 at 03:27:38PM -0700, Rich Clingman wrote:
> Exception while Reverting to earlier Revision. The intervening revisions had 
> tree conflicts that had been resolved by replacing. Reverting to have another 
> go at it.
> 

> Subversion reported the following:
> 
> In file 
> 'D:\Development\SVN\Releases\TortoiseSVN-1.6.16\ext\subversion\subversion\libsvn_subr\mergeinfo.c'
>  
> line 149: assertion failed (r1->start < r1->end)

Hmmm... This looks like mergeinfo somewhere got corrupted somehow?

a question about "svn merge"

[Boying.Lu]

Hi, All,

I use "svn merge ^trunk" to merge changes to my branch.

I found one file that shows no conflict but actually the changes were
not added to this file at all.

The subversion I use is 1.6.12.   Is is a known issue or a new bug?

Thanks

Boying

Re: a question about "svn merge"

[Stefan Sperling]

On Wed, Jun 22, 2011 at 04:36:17AM -0400, boying...@emc.com wrote:
> Hi, All,
> 
> I use "svn merge ^trunk" to merge changes to my branch.
> 
> I found one file that shows no conflict but actually the changes were
> not added to this file at all.
> 
> The subversion I use is 1.6.12.   Is is a known issue or a new bug?
> 

Very hard to tell without more information.
The reason could simply be that a user didn't carry out a merge correctly.

To argue that it is a bug, you'd need to present a script that runs
svn commands and shows the problem, starting off from an empty
repository, doing merges etc. until you get to the point where
the problem appears. That's the best way to demonstrate bugs, and
also a good way of starting someone off with getting the bug fixed.

Re: Evil UTF-8 Character in filename in repo causing issues on my wc

[Vincent Lefevre]

On 2011-06-15 12:29:37 +0200, Stefan Sperling wrote:
> Unicode, and it's quirk of allowing the *same* character to be encoded
> in *different* ways, came much later.
> 
> I think it is unfortunate that Apple broke with the concept that a
> filename is just a string of bytes.

It's also unfortunate that Subversion breaks this concept too. :)

I mean: do a checkout of a repository containing non-ASCII characters
under Linux. Then change the locales (e.g. ISO-8859-1 -> UTF-8). Do
an update. And see the errors...

> When they made this decision they probably considered that it might break
> applications and decided that the applications would have to adjust.

One problem is that different applications encode accented characters
(typed on the keyboard) differently: some of them use NFC, others use
NFD. If they aren't regarded as equivalent, you get problems. And
since Unicode doesn't standardize which one to use, one cannot blame
the applications.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Evil UTF-8 Character in filename in repo causing issues on my wc

[Stefan Sperling]

On Wed, Jun 22, 2011 at 03:42:42PM +0200, Vincent Lefevre wrote:
> On 2011-06-15 12:29:37 +0200, Stefan Sperling wrote:
> > Unicode, and it's quirk of allowing the *same* character to be encoded
> > in *different* ways, came much later.
> > 
> > I think it is unfortunate that Apple broke with the concept that a
> > filename is just a string of bytes.
> 
> It's also unfortunate that Subversion breaks this concept too. :)
> 
> I mean: do a checkout of a repository containing non-ASCII characters
> under Linux. Then change the locales (e.g. ISO-8859-1 -> UTF-8). Do
> an update. And see the errors...

I don't agree that this is the same problem. It's a different problem.

Subversion is internally converting path names from the native encoding
into UTF-8 and sends them to the repository because they are UTF-8-encoded
there. This way, all encodings used on client systems can be represented
in the repository. It works fine with client systems that do not support
UTF-8 natively at all, as long as they use some encoding that iconv
understands. And this is all happening *within* the application.
The rules that svn uses to create filenames are clear and consistent.
They require users not to flip locales willy-nilly, but that's the
tradeoff with relying on the locale. Locales only support one encoding
at a time.

What apple does is transform the byte sequence behind the application's back.
So the application itself cannot rely on its *own* rules it was using to
create filenames when it runs again and reads the names back from disk
because the OS is interfering with these rules. 

> > When they made this decision they probably considered that it might break
> > applications and decided that the applications would have to adjust.
> 
> One problem is that different applications encode accented characters
> (typed on the keyboard) differently: some of them use NFC, others use
> NFD. If they aren't regarded as equivalent, you get problems. And
> since Unicode doesn't standardize which one to use, one cannot blame
> the applications.

Yes, I fully agree here.

Re: Backporting features from trunk to 1.6.x

[Daniel Shahaf]

Stefan Sperling wrote on Tue, Jun 21, 2011 at 13:52:37 +0200:
> The backports simply fall under the terms of the old licence when
> they get released. But then again, the project owns copyright to
> these changes in the first place :)

The project does not own the copyright to an individual patch that's
backported to an older release branch.  (Neither ICLA transfers
copyright.)

Re: Evil UTF-8 Character in filename in repo causing issues on my wc

[Andreas Krey]

On Wed, 22 Jun 2011 16:28:31 +, Stefan Sperling wrote:
...
> Subversion is internally converting path names from the native encoding

Except that LANG isn't *the* native encoding. It is at least debatable
whether it should be used to interpret file system name strings.
(And it's rather hacked, since it is 'LANGuage' and not encoding, even
though there are locales like en_us.utf8.)

In my opinion it would be saner nowadays to assume file names to
be in utf8 and warn if they are not, and use the setting in LANG
for console I/O only.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Backporting features from trunk to 1.6.x

[Stefan Sperling]

On Wed, Jun 22, 2011 at 07:25:13PM +0300, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, Jun 21, 2011 at 13:52:37 +0200:
> > The backports simply fall under the terms of the old licence when
> > they get released. But then again, the project owns copyright to
> > these changes in the first place :)
> 
> The project does not own the copyright to an individual patch that's
> backported to an older release branch.  (Neither ICLA transfers
> copyright.)

Well, "the project" as in "the sum of its contributors, where each
owns a subset of the copyright on the collective work" :)

I'll now stop splitting hairs.

Re: Evil UTF-8 Character in filename in repo causing issues on my wc

[Stefan Sperling]

On Wed, Jun 22, 2011 at 07:09:22PM +0200, Andreas Krey wrote:
> In my opinion it would be saner nowadays to assume file names to
> be in utf8 and warn if they are not, and use the setting in LANG
> for console I/O only.

This strategy may work well for applications starting out today.
but it won't work for Subversion.

Not all operating systems have switched to UTF-8 as the default
character set yet. ASCII is still the only encoding that works
everywhere out of the box (especially on the console!).
E.g. Debian switched to UTF-8 by default for the Etch release in 2008.
http://www.debian.org/releases/etch/i386/release-notes/ch-whats-new.en.html
Many unixy systems that aren't Linux have not switched to UTF-8 by
default, and it is possible that some never will.
Subversion is supposed to be portable across all these platforms and
more.

Subversion was founded in 2000 and the first 1.0 release was in 2004,
which all subsequent 1.x releases need to stay compatible with (so
we cannot just change the default behaviour now).
UTF-8 is older than 2003, but received its most recent update in
RFC 3629 which is from 2003. It was fairly new stuff when Subversion
was originally developed, far from being the default on many systems.
Back in 2003 you couldn't just write UTF-8 to the screen or create
UTF-8 filenames and expect this to work well by default on all platforms.

I agree that locales aren't the ideal solution to this problem.
But at least they are standardized by POSIX and can be expected
to behave the same way everywhere. And they allow Subversion users
to say "yes, my system supports UTF-8, please use it".

The best solution would be a standardised way of specifying
filename encoding that works the same on all filesytem types in
all operating systems. Alas, that doesn't exist :(

I don't think the current solution is perfect. But it's a good
compromise given the circumstances.

How to setup SVN with HTTPS on Apache for Windows?

[Robert Dailey]

I currently run a Windows 2008 R2 server and I want to host SVN 1.7 on my
Apache installation, provided by XAMPP. Is there an easy to follow step by
step process I can follow to set this up? If not, can someone run me through
the basics?

-
Robert Dailey

Lost work due to non-cummutative merges

[Christoph Bartoschek]

Hi,

we have the following situation:

1. A branch is created from trunk.
2. In trunk a line of code is added and commited as revision X
3. The line is removed again and commited as revision X+1
4. In branch changeset X+1 is merged from trunk
5. In branch changeset X is merged from trunk.

The problem is now that in the branch the line is still there and one 
gets no warning from subversion that something is wrong.


Is this a bug in subversion?  Why isn't there at least a merge conflict 
for step 4?


Christoph

How to install Subversion in Apache on Windows?

[Robert Dailey]

I am currently running Windows Server 2008 R2 and I have Apache installed on 
it through XAMPP. Is there a simple tutorial that shows how to install 
either SVN 1.6 or 1.7 into my existing version of Apache? Ideally I'd like 
to use the https protocol with SVN to access my repository.

Thanks in advance.

Re: How to setup SVN with HTTPS on Apache for Windows?

[Rob van Oostrum]

The manual is always a good place to start:


http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html


Cheers,
Rob

On Wed, Jun 22, 2011 at 1:59 PM, Robert Dailey  wrote:
> I currently run a Windows 2008 R2 server and I want to host SVN 1.7 on my
> Apache installation, provided by XAMPP. Is there an easy to follow step by
> step process I can follow to set this up? If not, can someone run me through
> the basics?
>
> -
> Robert Dailey
>

Re: Possible bug moving file and then deleting directory

[Mark Phippard]

See http://subversion.apache.org/faq.html#self-tree-conflict

On Wed, Jun 22, 2011 at 4:04 PM, Patrick Quirk  wrote:

> **
>
> I’ve run into this issue the past few days and I don’t feel like this is
> expected behavior.  I’m using client version 1.6.17 (Collabnet binaries).*
> ***
>
>  
>
> Simply put, I move a single file, commit that, then try to delete the
> directory the file was in (it’s empty now) and commit that.  This fails,
> saying the directory I’m attempting to commit/delete is out of date.  If I
> update it, I get a tree conflict.  
>
> ** **
>
> Am I wrong in expecting this to work without an update in the middle?  I’ve
> provided a batch file to reproduce the behavior on a Windows machine (unzip
> and then change the file’s extension to .bat).
>
>  
>
> Thanks
>
> Patrick
>
> ** **
>
> ** **
>
> ** **
>
> 
>
> **Patrick Quirk**
> GEM Software Engineer
> 3511 University Drive
> Durham** **NC** **27707
> 919-354-4762
> p.qu...@smt.com 
> www.sportsmedia.com 
>
> ** **
>



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/
<>

Re: How to setup SVN with HTTPS on Apache for Windows?

[Geoff Hoffman]

Get everything working as a regular http://server/svn/repo then get a cert
or self sign (not related to svn) and move your vhost to port 443 (open that
port on your firewall if applicable).

Re: How to setup SVN with HTTPS on Apache for Windows?

[Robert Dailey]

Thanks guys and I apologize if you guys got my double-post. That was a
user-error.

-
Robert Dailey


On Wed, Jun 22, 2011 at 3:46 PM, Geoff Hoffman wrote:

> Get everything working as a regular http://server/svn/repo then get a cert
> or self sign (not related to svn) and move your vhost to port 443 (open that
> port on your firewall if applicable).

Re: Possible bug moving file and then deleting directory

[Johan Corveleyn]

It seems this behavior has changed in 1.7 (to be released soon). It will no
longer flag this as a tree conflict. See
http://subversion.tigris.org/issues/show_bug.cgi?id=3526.

AFAICS, the case described here is similar to the one described in issue
#3526.

Patrick, if you have some time, maybe you can test this with one of the
pre-releases of 1.7? See
http://subversion.apache.org/packages.html#pre-release.

Cheers,
-- 
Johan

On Wed, Jun 22, 2011 at 10:44 PM, Mark Phippard  wrote:

> See http://subversion.apache.org/faq.html#self-tree-conflict
>
>
> On Wed, Jun 22, 2011 at 4:04 PM, Patrick Quirk  wrote:
>
>> **
>>
>> I’ve run into this issue the past few days and I don’t feel like this is
>> expected behavior.  I’m using client version 1.6.17 (Collabnet binaries).
>> 
>>
>>  
>>
>> Simply put, I move a single file, commit that, then try to delete the
>> directory the file was in (it’s empty now) and commit that.  This fails,
>> saying the directory I’m attempting to commit/delete is out of date.  If I
>> update it, I get a tree conflict.  
>>
>> ** **
>>
>> Am I wrong in expecting this to work without an update in the middle?
>> I’ve provided a batch file to reproduce the behavior on a Windows machine
>> (unzip and then change the file’s extension to .bat).
>>
>>  
>>
>> Thanks
>>
>> Patrick
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> 
>>
>> **Patrick Quirk**
>> GEM Software Engineer
>> 3511 University Drive
>> Durham** **NC** **27707
>> 919-354-4762
>> p.qu...@smt.com 
>> www.sportsmedia.com 
>>
>> ** **
>>
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
<>

Re: Lost work due to non-cummutative merges

[Daniel Shahaf]

I also expected step 4 to conflict, and I also don't get a conflict:

[[[
9,% ./new.sh 
### Making a Greek Tree for import...
### Done.

### Importing it...

Committed revision 1.
### Done.

9,% cd wc1/trunk/
9,% $svn cp -q A A2
9,% $svn ci -q -m branch
9,% :>A/mu
9,% $svn ci -q -mrm A
9,% $svn up -q
9,% cp A2/mu A/mu
9,% $svn ci -q -madd A
9,% $svn up
Updating '.':
At revision 4.
9,% $svn merge -c 4 A A2
--- Recording mergeinfo for merge of r4 into 'A2':
 U   A2
9,% $svn ci -mmerge   
SendingA2

Committed revision 5.
9,% cat A2/mu
This is the file 'A/mu'.
9,% 
]]]

Maybe Johan can explain that :)

Christoph Bartoschek wrote on Wed, Jun 22, 2011 at 21:25:29 +0200:
> Hi,
> 
> we have the following situation:
> 
> 1. A branch is created from trunk.
> 2. In trunk a line of code is added and commited as revision X
> 3. The line is removed again and commited as revision X+1
> 4. In branch changeset X+1 is merged from trunk
> 5. In branch changeset X is merged from trunk.
> 
> The problem is now that in the branch the line is still there and
> one gets no warning from subversion that something is wrong.
> 
> Is this a bug in subversion?  Why isn't there at least a merge
> conflict for step 4?
> 
> Christoph

Re: Possible bug in SVN server with MIME formatted files

[Daniel Shahaf]

Can't reproduce with either neon or serf.

9,% $svn add recover.eml 
A recover.eml
9,% $svn ci -madd
Adding recover.eml
Transmitting file data .
Committed revision 2.
9,% $svn up
Updating '.':
At revision 2.
9,% echo>>iota
9,% $svn ci -mappend
Sendingiota
Transmitting file data .
Committed revision 3.
9,% $svn rm *eml
D recover.eml
9,% $svn ci -mm
Deleting   recover.eml

Committed revision 4.
9,% 

Nuno Cruces wrote on Wed, Jun 22, 2011 at 19:59:37 +0100:
> Hi,
> 
> I believe I have found a bug the subversion server.
> 
> It seems that, after committing a MIME formatted file (such as the
> one attached), I can't do anything to the file.
> 
> Committing changes, returns the following:
> 
> Commit failed (details follow):
> CHECKOUT of
> '/(.)/recover.eml':
> Could not read status line: connection was closed by server
> (http://.ydreams.com)
> 
> Deleting the file, returns the following:
> 
> Commit failed (details follow):
> OPTIONS of
> '/(.)/recover.eml':
> Could not read status line: connection was closed by server
> (http://.ydreams.com)
> 
> I'm on windows, and have tried multiple clients, which is why I've
> assumed it is a problem with the server. The clients which I have
> tried were:
> TortoiseSVN, AnkhSVN and SlikSvn (the command line client).
> 
> I assume the server is running on Windows too, and you can see we're
> using SVN through HTTP. I haven't tried it through other protocols,
> since they are disabled on this particular server.
> 
> The rest of the repository is available and working. I can checkout
> the project (this file included). I can delete or modify other files
> and commit changes. It's just these two particular files (both MIME
> formatted "email template" files) that are the issue.
> 
> I can try to dig this further, but would appreciate guidance.
> 
> Thanks,
> Nuno Cruces

Re: Evil UTF-8 Character in filename in repo causing issues on my wc

[Vincent Lefevre]

On 2011-06-22 16:28:31 +0200, Stefan Sperling wrote:
> On Wed, Jun 22, 2011 at 03:42:42PM +0200, Vincent Lefevre wrote:
> > On 2011-06-15 12:29:37 +0200, Stefan Sperling wrote:
> > > Unicode, and it's quirk of allowing the *same* character to be encoded
> > > in *different* ways, came much later.
> > > 
> > > I think it is unfortunate that Apple broke with the concept that a
> > > filename is just a string of bytes.
> > 
> > It's also unfortunate that Subversion breaks this concept too. :)
> > 
> > I mean: do a checkout of a repository containing non-ASCII characters
> > under Linux. Then change the locales (e.g. ISO-8859-1 -> UTF-8). Do
> > an update. And see the errors...
> 
> I don't agree that this is the same problem. It's a different problem.

I'm not saying that's the same problem, but that Subversion doesn't
regard a filename as a string of bytes.

> Subversion is internally converting path names from the native encoding

If you regard a filename as a string of bytes, there isn't a concept
of native encoding.

> into UTF-8 and sends them to the repository because they are UTF-8-encoded
> there. This way, all encodings used on client systems can be represented
> in the repository. It works fine with client systems that do not support
> UTF-8 natively at all, as long as they use some encoding that iconv
> understands. And this is all happening *within* the application.
> The rules that svn uses to create filenames are clear and consistent.

There aren't consistent, because svn doesn't track the encoding used
to create the filenames. GNOME rules are consistent: the encoding is
always UTF-8.

> They require users not to flip locales willy-nilly, but that's the
> tradeoff with relying on the locale. Locales only support one encoding
> at a time.

Yes, but different processes can use different locales, and this breaks
svn. There's a good reason why locales are set via environment variables
(on POSIX systems) and not globally.

> What apple does is transform the byte sequence behind the
> application's back.

This is not behind application's back, because this is documented in
the API. The application writer should follow the API.

What's more important is that both Mac OS X and svn (e.g. under Linux)
can transform the byte sequence in the *user's* back. For Mac OS X,
this is related to the normalization form, and for svn, this is related
to the locales.

> So the application itself cannot rely on its *own* rules it was using to
> create filenames when it runs again and reads the names back from disk
> because the OS is interfering with these rules. 

I think it's great to have standards, system-wide conventions and things
like that to avoid applications choosing their own rules. So, I wouldn't
blame Mac OS X for that.

Because there are drawbacks to any choice regarding the filenames,
it would be better to make things configurable at the user level,
but hardcoding choices in applications is bad, IMHO.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Lost work due to non-cummutative merges

[Daniel Shahaf]

I used a recent-ish trunk build.

Daniel Shahaf wrote on Thu, Jun 23, 2011 at 03:03:05 +0300:
> I also expected step 4 to conflict, and I also don't get a conflict:
> 
> [[[
> 9,% ./new.sh 
> ### Making a Greek Tree for import...
> ### Done.
> 
> ### Importing it...
> 
> Committed revision 1.
> ### Done.
> 
> 9,% cd wc1/trunk/
> 9,% $svn cp -q A A2
> 9,% $svn ci -q -m branch
> 9,% :>A/mu
> 9,% $svn ci -q -mrm A
> 9,% $svn up -q
> 9,% cp A2/mu A/mu
> 9,% $svn ci -q -madd A
> 9,% $svn up
> Updating '.':
> At revision 4.
> 9,% $svn merge -c 4 A A2
> --- Recording mergeinfo for merge of r4 into 'A2':
>  U   A2
> 9,% $svn ci -mmerge   
> SendingA2
> 
> Committed revision 5.
> 9,% cat A2/mu
> This is the file 'A/mu'.
> 9,% 
> ]]]
> 
> Maybe Johan can explain that :)
> 
> Christoph Bartoschek wrote on Wed, Jun 22, 2011 at 21:25:29 +0200:
> > Hi,
> > 
> > we have the following situation:
> > 
> > 1. A branch is created from trunk.
> > 2. In trunk a line of code is added and commited as revision X
> > 3. The line is removed again and commited as revision X+1
> > 4. In branch changeset X+1 is merged from trunk
> > 5. In branch changeset X is merged from trunk.
> > 
> > The problem is now that in the branch the line is still there and
> > one gets no warning from subversion that something is wrong.
> > 
> > Is this a bug in subversion?  Why isn't there at least a merge
> > conflict for step 4?
> > 
> > Christoph

Re: Evil UTF-8 Character in filename in repo causing issues on my wc

[Vincent Lefevre]

On 2011-06-22 19:34:08 +0200, Stefan Sperling wrote:
> On Wed, Jun 22, 2011 at 07:09:22PM +0200, Andreas Krey wrote:
> > In my opinion it would be saner nowadays to assume file names to
> > be in utf8 and warn if they are not, and use the setting in LANG
> > for console I/O only.
> 
> This strategy may work well for applications starting out today.
> but it won't work for Subversion.
> 
> Not all operating systems have switched to UTF-8 as the default
> character set yet. ASCII is still the only encoding that works
> everywhere out of the box (especially on the console!).
> E.g. Debian switched to UTF-8 by default for the Etch release in 2008.
> http://www.debian.org/releases/etch/i386/release-notes/ch-whats-new.en.html
> Many unixy systems that aren't Linux have not switched to UTF-8 by
> default, and it is possible that some never will.

Debian still supports non-UTF-8 locales. That's useful when one
connects from a non-UTF-8 terminal with SSH. And that's precisely
why the user may need to use different locales on some machine
(just for consistent terminal I/O).

> Subversion is supposed to be portable across all these platforms and
> more.

Tracking the filename encoding or letting the user choose the filename
encoding wouldn't be against portability.

Also portable scripts need to use LC_ALL=C. And again, this breaks
svn as soon as a filename has non-ASCII characters (even though such
a filename doesn't appear anywhere in the svn arguments).

> I agree that locales aren't the ideal solution to this problem.
> But at least they are standardized by POSIX and can be expected
> to behave the same way everywhere.

Not everything is standardized (e.g. locale names and what they provide
are system specific). And under POSIX, each process can have its own
locale (and change it).

> And they allow Subversion users to say "yes, my system supports
> UTF-8, please use it".

But what if the system supports UTF-8, but the terminal doesn't?

> The best solution would be a standardised way of specifying
> filename encoding that works the same on all filesytem types in
> all operating systems. Alas, that doesn't exist :(

When there's no standard, let the user choose (with a good compromise
for the default behavior).

> I don't think the current solution is perfect. But it's a good
> compromise given the circumstances.

It really isn't. Tracking the filename encoding is a must.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Exclude a directory from a copy.

[Gavin Baumanis]

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.

As always - thanks!

Gavin "Beau" Baumanis

Re: Exclude a directory from a copy.

[Ryan Schmidt]

On Jun 22, 2011, at 21:01, Gavin Baumanis wrote:

> 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.

That should work. Since Subversion copies are efficient, the above shouldn't be 
a waste of space. You would only need to watch out that when you merge the 
branch back, that you don't end up accidentally removing this directory from 
the trunk as well.