Thanks a lot Josh; I've re-arranged and snipped the quoting below to
help my responses make more sense, as well as including my original
post as a while has passed since then.
On 5/2/07, Josh Gilkerson <jwg@google.com> wrote:
> 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.
That's exactly what I was looking for. So merge won't propagate tree
changes in B (in this case adding new directories full of files and
sub-directories) to C, that needs to be done manually in C before the
merge. Not that I'd want to, but for the sake of understanding, if I
pre-populated C with all of B's directory structures, but it was empty
of files, then I wouldn't get the missing target errors?
> 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.
That is correct.
>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.
But what I'm trying to end up with in this case is a non-versioned
"working" tree of A, with only the "my stuff" customisations from the
B branch under version control.
It's a XAMPP installation that needs to fit on media with limited
space (USB stick) and I know there won't be any changes to the core
Apache/PHP etc. stuff, but I want to keep my config file and content
changes (currently less than 1% of the total disk space) under version
control without doubling up on the space (300+MB) taken up by the
non-changing 99%.
When Apache Friends come out with the next XAMPP version, I'll use my
A tree to track what's changed in the "virgin" file set and then merge
from there into B, as you say standard procedure.
But while A is stable, I'll use your approach below to track only my
customisation:
> 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 .
Actually I'd be exporting A, but checking out B, as I do want to
continue to keep my customisation, configuration and content files
under version control.
> 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.
No problem either way, I can export to two separate locations and then
just use an external xcopy B over A to get my customised version.
> 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.
As far as Subversion is concerned, these will be two completely
separate projects, and only the B tree will be under version control
in the tree which I "merged" with the xcopy, since A was exported it
will just treat these files and directories as normal unversioned
files, right? It might be "strange" compared to the normal use case,
but I can't see how it will cause problems. . .
Original posting:
On 5/1/07, hans henderson <hans.svn@gmail.com> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 6 07:07:12 2007