svn - 2 'packages' one using elements of the other, best way to structure this?

Question

Hi, I have what I believe is a tricky situation but this usually indicates I'm ignorant of something quite simple.

I currently have one php project that is in an svn repo, call it 'firstproject'. The working copy of this is an apache virtual host dir so I can happily run this project at any point of development through a browser. I now have another project 'newproject' that I want to use some of the core code of 'firstproject' but when newproject requires me to refactor parts of the firstproject classes I would like for that to be integrated back into firstproject at some point.

Is there any way to set svn up so I can have a working copy of newproject happily in it's own apache virtual host and comprising some code from firstproject and then its own code and for svn to keep tabs on which is which or is it a case of creating a 'newproject' branch of firstproject, editing away adding the newproject code and then doing some sort of merging of code back into 'firstproject' when it seems appropriate?

Many thanks to anyone who can help me thinking about this, it feels like there should be a neat way but maybe there isn't.

Answer 1

It seems to me that firstproject should release some deliverable (a library). newproject can then consume this.

If that library needs to change, then the changes should be made in firstproject, and released.

That's how I'd normally manage this sort of dependency in a non-PHP world. I'm not sure that in PHP it should/would be any different. It's a bit of a headache, but you're building a reusable library that a downstream project can consume (and choose which version it consumes, note).

Answer 2

If there is a large part of the code that is common, then you can consider using a common repository instead of two seperate repositories for these two projects. You can then take out a branch for the code that might change within the project newproject . The workspace on the newproject apache server will have to be from this branch so that any changes can be committed back to the branch and merged back to the trunk when you are ready. This way you can incorporate the changes back to the firstproject mainline/trunk.

You can also explore svn externals for another approach to mix and match if you need a workspace with checkouts from multiple repositories. I have not implemented this myself but you may find the details here: http://svnbook.red-bean.com/en/1.1/ch07s04.html