We are currently doing this using svn merge. We merge the trunk into our
working copy of the branch, something like this (not at my work pc at the
moment...so it could be wrong)
svn merge -r[last-merge-from-trunk]:HEAD url/to/trunk .
We use a script to do this and it stores the [last-merge-from-trunk] value
in a property which it uses the next time you run the script. It seems to
work pretty well as only the changes in the trunk since the last time you
merged are merged into your branch. (and you only have one commit)
Gareth
> -----Original Message-----
> From: Ian P. McCullough [mailto:ipm+@andrew.cmu.edu]
> Sent: 16 January 2004 08:26 PM
> To: users@subversion.tigris.org
> Subject: Understanding copying/replacing
>
> I've been kind of puzzled as to how I shoudl be mapping my particular
> development situtaion to the subversion branch model. So far
> I've been
> kind of flailing so I figured I'd poll the other users to see
> if there are
> any "best practices" out there.
>
> I develop a web application. There is a "core application"
> and then I also
> make customized versions of the application for various
> clients. When I
> start a new customization project, I make an "svn cp" of my
> core directory,
> and then I proceed with the customization work from there.
>
> The problem I have is that occasionally (read almost daily) I
> make bug
> fixes to the core application which then need to be
> propagated to some or
> all of the branches.
>
> It appears to me that "svn merge" is NOT what I want to do
> here because I
> dont want any of the custom stuff to be ported back into the
> core, nor do I
> want the custom branch to be identical to the core because it
> may have
> customizations. Often these changes include a small change
> to one file.
>
> My next thought was that I should "svn rm" the custom version
> and then "svn
> cp" the new, fixed version of the file from the core
> application directory
> to the custom version directory. This is what I have been
> doing, however
> when working with multiple files, this gets very tedious.
> Also it seems
> that every time you execute an "svn rm" on a URL it wants to
> commit. So if
> I want to delete 100 files (but not a whole directory), its
> going to end up
> committing 100 times. I know that version numbers are
> arbitrary, but this
> seems like a great way to make the history unusably large
> really quickly.
>
> Next it seems that if I try to do the rm/cp solution in a
> working copy that
> its going to take two commits. Is there no way to replace a
> file with
> another file in one commit?
>
> I also tried, for a while, "OS copying" the new version over
> the working
> copy in the custom branch, which works great but then its not
> clear from
> looking at the history that the file has been replaced by a
> version from
> the main branch since the original creation of that custom branch.
>
> Overall the best solution so far seems to be "svn rm; svn cp"
> procedure
> along with all the commits that procedure entails... Am I
> missing something?
>
> Thanks,
> Ian
>
> ----------------------------------------------------------------
> Ian P. McCullough
> Sr. Information Systems Specialist
> Center for Arts Management and Technology (CAMT)
> H. John Heinz III School of Public Policy and Management
> Carnegie Mellon University
> Pittsburgh, PA 15213-3890
> (412) 268-3748
> FAX (412) 268-3590
> ipm@andrew.cmu.edu
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 16 19:54:48 2004