Branching a trunk permanently

I am wondering how someone else would achieve what I am trying to do here. Basically I have a development trunk for Project A. It is updated with new code on a daily basis and has frequent branches and merges for various features etc..

I have taken a project trunk and created a completely new project from it. I am doing this because the new trunk will go off it’s own development path and I don’t want modifications on Project B to create problems in Project A. In addition, namespaces in Project B will be different. This part is no problem. The problem I have is how to effeciently transmit updates to code from one project to the other. From time to time there may be new features added that I want to add to one project or the other but not all the time.

I thought about using patches and haven’t thought about it much recently. I’m at the point now where Project A has quite a few features that I wish to add to Project B without having to copy and paste code although this is what I may have to resort too.

I guess the bottom line is, there feels like there is an easier way to do this, if there is I haven’t found it yet =)

About Sean Chambers

I am a Senior software developer from Palm Coast, Florida. An advocate of Domain Driven Design, Behavior Driven Development, creator of FluentMigrator and community activist. I am married to my beautiful wife Erin and am the proud father of two wonderful children. I currently reside at ACI, a local insurance industry/mortgage software company that excels in creating solutions using Agile methodologies.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • In these situations where you really are working with 2 different projects, I would try to “harvest” out those “features”, if possible, into their own assembly and share it across projects. I’m a firm believer that a Project (as in usually one or a few solutions, not VS Projects) should be careful about what code it “owns/trusts”, at least in the form of code. Anything that is not “owned” by my current Project, I treat as a 3rd party library (trunk\lib).

    As most of us know by now, one of the best ways to make reusability achievable is to extract out features/frameworks from existing *working* applications.

    I’m sure there are other (probably better) ways for dealing with this, but this is how I’ve usually approached it.

  • I see Joe. Good advice.

    I’m going to take another look at the code base since it’s been a week or two since I’ve worked with it and see really how out of date it is.