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

Re: Tagging *only* the changes in a branch

From: hans henderson <hans.svn_at_gmail.com>
Date: 2007-05-02 04:37:23 CEST

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
Received on Wed May 2 04:37:40 2007

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.