> -----Original Message-----
> From: Mark Wagner [mailto:carnildo_at_gmail.com]
> Sent: Monday, March 09, 2009 2:02 PM
> To: Holger Stratmann
> Cc: users_at_subversion.tigris.org
> Subject: Re: Converting a revision to a patch
> On Sun, Mar 8, 2009 at 16:09, Holger Stratmann <tigris_at_finch.de>
> > No seriously: It's never too late to put source code under version
> > is it?
> > What are you doing with the unmanaged copy and why do you need to
> > patches to it? Will you need any more patches in the future?
> We started revision control for this product with version 8. I've had
> a request to apply a bugfix from a recent version of the code to
> version 7.4 to create a "version 7.5" release. Development is being
> done on Macintosh systems, and all versions of the source code before
> 8 have files with resource forks, which makes it a royal pain to use
Minus the resource forks issue, we have a similar scenario. Based on
what we're doing, I'd suggest this to you:
1. Make a version 7 directory (depending on how you work, this might be
a new directory at or near the root, or a subdirectory of /branches).
2. Copy your earliest version 8 directory into there.
3. Check out your early version 8 code.
4. Use a 2-way merge tool to basically replace the version 8 code with
version 7 code (specifically 7.4).
5. Commit the 7.4 code.
6. Make a 7.4 tag from your committed code.
7. Copy your 7.4 tag somewhere for 7.5 development.
8. Check out your 7.5 code.
9. Merge your desired version 8 revision.
10. Commit to 7.5 (or produce a patch file from your merge results if
that is what you really want).
The main trick is that in step 4 you're committing a revision that takes
you backwards from version 8 back to version 7.4. From there you have
hopefully enough useful ancestry to merge your version 8 revision.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-09 21:46:01 CET