Comments on: Branching a trunk permanently http://lostechies.com/seanchambers/2007/09/27/branching-a-trunk-permanently/ Just another LosTechies site Thu, 13 Sep 2012 07:11:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Sean Chambers http://lostechies.com/seanchambers/2007/09/27/branching-a-trunk-permanently/#comment-32 Sean Chambers Fri, 28 Sep 2007 00:01:54 +0000 /blogs/sean_chambers/archive/2007/09/27/branching-a-trunk-permanently.aspx#comment-32 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. thanks! 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.

thanks!

]]> By: joeyDotNet http://lostechies.com/seanchambers/2007/09/27/branching-a-trunk-permanently/#comment-31 joeyDotNet Thu, 27 Sep 2007 23:04:34 +0000 /blogs/sean_chambers/archive/2007/09/27/branching-a-trunk-permanently.aspx#comment-31 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. 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.

]]>