NYCPHP Meetup

[Dan Cech]

Cliff Hirsch wrote:
>> Basically you create a branch with the upstream release you are
>> currently using, then apply patches from upstream to that branch to keep
>> it in sync with the upstream version.
>>
>> At any time you can then merge those changes into your development
>> branch, taking advantage of svn's built-in conflict resolution system to
>> handle any issues, rather than just getting stuck with patches that
>> won't apply cleanly.
> 
> I think I got the message. So this is the appropriate time to create a
> branch. My current base become trunk and perhaps tag it as V1; make a V2
> branch of this; make my working copy point to the new branch, apply the
> vendor's upgrade, then -- when I'm ready, merge the branch into the trunk?
> Is that the jist of it?
> 
> Use a repository structure like this?
> http://svn.collab.net/viewvc/svn/

Cliff,

I would strongly recommend that you read the svn book
(http://svnbook.red-bean.com/), which will answer many of your questions.

By using the vendor branch mechanism outlined in chapter 7, you can
solve the problem you are facing the right way and avoid future
headaches.  A vendor branch is not the same thing as a 'normal' branch
used for feature development, and you will need to have a solid grasp of
svn fundamentals to avoid getting yourself into trouble.

Dan