Re the bin directory, it looks like Evil Eclipse copied my src/.svn directory as resource files to my output bin directory. TSVN shows it as a version-controlled folder, so my assertion that the bin directory was under version control was wrong.
Then I tried addressing the other issue, got frustrated, and deleted my trunk WC contents to update to a fresh one. Then the merge worked, go figure. I don't understand how I screwed up the WC so much. I don't really want to blame it on Evil Eclipse either ;-)
FYI, if you do "svn merge help" after the help, a message "svn: Wrong number of paths given" appears. The correct command is "svn help merge" of course, but since the first form works more or less, they should/could act the same with no error message?
- Simon
> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: Monday, April 26, 2004 5:40 PM
> To: Simon McClenahan
> Cc: Subversion Users (E-mail)
> Subject: RE: Merging a second-order branch
>
>
> On Mon, 2004-04-26 at 17:27, Simon McClenahan wrote:
> > I did the merge as described from the command-line. I'm going to
> > assume for now that TortoiseSVN doesn't support this type of merge
> > operation. A couple more questions:
> >
> > - I was surprised to see some files were skipped. Was this
> because of
> > a configuration somewhere, or because svn merge decided?
> Something to
> > do with dot-files?
> > Skipped '.classpath'
> > Skipped '.project'
> >
> > - In the trunk, there was a "bin" directory under version control,
> > which I svn deleted in my branch. Shouldn't the merge have
> deleted the
> > directory, or at least the hidden .svn dir? I have another branch
> > where I am doing some major re-organizing of directories and file
> > moving. Should I be anticipating problems like this when I
> merge back
> > to the trunk?
>
> 'svn merge' *does* understand additions, deletions, copies,
> and renames.
>
> Both of these descriptions are classic symptoms of an
> "unclean patch".
> In other words, you're comparing two trees (say, tree A and
> tree B), and
> the resulting diff is a patch which doesn't cleanly apply to your
> working copy.
>
> When you see messages about skipping, it typically means that
> tree A and
> tree B both have an object, but your working copy doesn't.
> For example,
> if the comparison between tree A and tree B results in a patch which
> says, "make this tweak to foo.c", but your working copy has no such
> file, then you get a "skipped" message. It's analogous to the 'patch'
> program complaining about "failed hunks".
>
> Similarly, are you *sure* that a comparison between tree A and tree B
> would include a deletion of the 'bin' dir? Try 'svn ls'ing the two
> trees to verify.
>
> The upshot here is that you've somehow compared the wrong two trees,
> and/or tried to apply the patch to the wrong working copy location.
>
>
>
--------------------------
NOTE: This message and any included attachments are from HealthCom Partners, LLC and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 29 21:38:08 2004