The assumption when doing svn merge A B C is that A and C are
'similar'. Usually A is derived from C or C is derived from A or they
are derived from a common source.
You are getting the directory errors because the diff between A and B
says we added this file to directory a and a doesn't exist.
While I don't know exactly what you're trying to do, it sounds like
the following might be what you want to do.
1. create A and populate
2. create an empty branch B and check out to wB.
3. in wB do svn export A .
4. add your B-only files and any directories that contain them(using
svn add -N).
5. to create a distribution image ( or whatever), svn export A . ; svn
export B .
I haven't tested this last part. I'm not sure if the export will
complain about existing files/directories, but it would look something
like this.
All that being said, this seems like a very strange way of doing
things and you will almost undoubtedly run into problems if you do
this.
If I guess correctly at what you might want to do, I assume that you
want to independently update A, for instance A might be a tarball of
files you get from someone else. In this case, a more robust approach
might be
1. create A and populate with A-1.tar. tag/copy A to A1
2. copy A to B.
3. make your changes in B.
4. when A-2 comes out
4. a. check out A to wA, untar A-2.tar over wA, svn add new files, etc
4. b. check in wA
4. c. tag/copy A to A2
5. propagate changes to B
5. a. checkout B to wB
5. b. get the changes: svn merge A1 A2 wB
5. c. resolve conflicts, etc and check in
6. ???
7. profit
This is a pretty standard approach to maintaining parallel branches.
If you then really want to pull out the files that are changed, svn
diff --summarize A B will tell you what files are different.
On 5/1/07, hans henderson <hans.svn@gmail.com> wrote:
> OK, OK I'm a noob, I've only 60 hours with it in total so far. But
> unlike most I've in fact not only read the book but I've created an
> 800+ line text file of summary notes on it, and I'm constantly
> referring to it, doing usenet searches etc. as I'm working in svn.
>
> I accept that I may be trying to do things for which svn wasn't
> intended, but I doubt if I'm the first to do so, and such usage is
> rarely a truly bad thing. Obviously if I can't get it to work the way
> I want it to, I will find and use other tools to get to where I need
> to go.
>
> But to help my understanding (and that of others reading the archive
> later), I'd really appreciate it if someone could at least explain
> what specifically I'm missing about the svn merge command. If there's
> another, more appropriate place for me to get my question answered,
> feel free to direct me there.
>
> Note I'm *not* asking "please tell me how to make it do what I want" -
> I just want to understand the condition that is causing the skipped
> and skipped target error messages.
> ------
> "Compare version A (before) to B (after) and apply the change set to WC."
>
> If new directories and files were added between A and B, I would
> assume that they would be included in what gets copied to WC.
>
> The book states "the user is most likely comparing the wrong two
> trees; they're the classic sign of user error." In my particular use
> case A and B are maybe 80% the same, just a lot of new files and
> folders added to A to get to B, with two files modified.
>
> So I'm guessing the problem is with my WC being empty; but I don't
> understand why that stops the copy from happening, that's just an
> extreme extension of a normal missing subfolders situation, isn't it?
>
>
> On 5/2/07, Ryan Schmidt <subversion-2007b@ryandesign.com> wrote:
> >
> > On May 1, 2007, at 10:28, hans henderson wrote:
> >
> > > Scenario:
> > >
> > > Branch A is my relatively static "core", gets re-used for multiple
> > > projects, usually via export rather than checkout. However, for the
> > > process being discussed here, I could go either way; for now, lets say
> > > I check it out to wcA.
> > >
> > > So I make my changes in the wcA tree - FYI if it helps, not
> > > deleting/renaming or moving any directories or files, just adding
> > > (using svn add of course) and modifying them.
> > >
> > > OK, everything's working fine with my customisations, now I want to
> > > upload *just my changes* to a new empty branch. The ultimate goal
> > > being to be able to export branch A and then checkout only my modified
> > > files right over the top of the whole tree, these files to be under
> > > version control and not all the rest, using svn status -q to screen
> > > out the files I'm ignoring.
> > >
> > > An analogy from my old DOS days - from the top of a tree, "attrib -m
> > > /s". Do your work, then when you want to copy out only the files that
> > > are new or modified, "xcopy /aa /s" to a new tree. Am I dating myself
> > > or what? <g>
> > >
> > > Here's what I tried:
> > >
> > > Copied Branch A to Branch B directly via URLs in the repos, checked
> > > out from there, made all my changes and committed back up to B.
> > >
> > > Created a new empty Branch C, checked that "nothingness" out to wcC,
> > > and then did an "svn merge A B wcC". My logic was that the merge would
> > > take my A->B changeset and create a new tree with just the changes in
> > > wcC. But no, all I got was screens full of error messages about
> > > skipping all the directories, skipping "missing target" for each file,
> > > at the end got only one file that was new in the root.
> > >
> > > This seems very strange to me, as if the merge command isn't able to
> > > create new files and folders in the working copy? Do I need an empty
> > > directory tree in wcC first?
> > >
> > > Obviously I'm most interested in how to accomplish my objective, but
> > > I'd also like to know what I'm not understanding about the merge
> > > command, even if that's not part of the solution.
> > >
> > > Thanks in advance for your help.
> >
> > My best advice to you is: that's not really how Subversion works.
> > Read the book at http://svnbook.org to understand how Subversion does
> > work.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Josh Gilkerson
Software Engineer
Google, Inc · MV-1600 Plymouth (HQ)
+1 (650) 253-1667 direct
+1 (859) 608-7827 cell
jwg@google.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 2 06:23:15 2007