Hi Kevin,

Thanks for the background. Given the scenario you have presented I'm trying to 
think how you would handle it without doing baseless merges? The remembering of 
merge resolutions is interesting, although I would have thought that if a merge 
resolution is required the need to intelligently merge that code next time may 
be increased (assuming continuing activity in the same area of code).

Anyway - looks like you are up for an interesting challenge either way :)

From: [email protected] [mailto:[email protected]] On Behalf Of 
[email protected]
Sent: Tuesday, 31 March 2009 9:27 AM
To: [email protected]
Subject: RE: Starting on a new TFS add-on

Mitch,

Thanks for the response and interest.  I'll be putting information like this up 
on the web site when it is running, so you'll be able to get a better feel for 
it then.

The short answer is that you can keep things separated, but still have a way of 
doing continuous integration on the combined feature set.

I have a few use case scenarios in mind.  One use case relates to feature 
branches.  A lot of teams up until now have been hesitant to create feature 
branches because they feel like it is deferring a huge merge problem until the 
end of the project, which defeats the purpose of doing continuous integration 
and testing.  They just check everything into the trunk, but that's not a very 
good solution all the time because now your trunk is potentially unstable.  The 
automated merge tool strives to create a happy medium in these cases.

Suppose you create three feature branches, A, B, and C.  But you'd also like to 
do a continuous integration build on the combined feature set.  So you create a 
fourth branch called A+B+C.  The automated merge tool can then be configured to 
automatically merge A, B, and C into the A+B+C branch.  The tool will allow 
manual conflict resolution when needed, and will "memorize" conflict 
resolutions in order to be able to "replay" them later.

Now suppose features A and B are completed, but feature C is taking a lot 
longer than was expected.  If everything was mixed together on the trunk, you 
would have a hard time extracting C back out of it.  But since you kept them 
separate, you can now just create a branch called A+B, auto-merge A and B into 
it, do your final testing and ship the product.  This implies a baseless merge, 
which the product will be designed to support.  After you ship, you then merge 
A+B up to the trunk, rebase the C branch to the tip of the trunk, and keep 
working.

Thoughts?


-          Kevin

From: [email protected] [mailto:[email protected]] On Behalf Of Mitch Denny
Sent: Monday, March 30, 2009 3:49 PM
To: [email protected]
Subject: RE: Starting on a new TFS add-on

Hi Kevin,

I have to ask, automatic merging seems like it defeats the purpose of 
branching, so why build the tool? Not trying to deflate you, just want to 
understand the reasons because I would have thought that you created the branch 
for a reason.

From: [email protected] [mailto:[email protected]] On Behalf Of 
[email protected]
Sent: Tuesday, 31 March 2009 5:33 AM
To: [email protected]
Subject: Starting on a new TFS add-on

Hi All,

For the last several months, I've been contemplating some SCM add-in tools that 
are of interest to me, and hopefully to others as well.  I've paid particular 
attention to tools that will be of use to TFS users.

I have decided to begin work on an automated merging tool.  I will be getting 
the web site up and running soon, and announcing an early access program for 
those that would like to be a beta tester and give me feedback.

The product will be designed for teams that have complex branching/merging 
scenarios, including service pack branches, branches for customized versions of 
the software, feature branches, team branches, etc.  The tool will make it much 
easier for teams to manage frequent check-ins and builds in these environments. 
 Initially I will be supporting TFS and Subversion, and possibly a couple other 
SCM tools (ClearCase, Perforce, ?).

Wish me luck!  If anyone has any thoughts on this subject, I'd love to hear 
them.

Thanks.

-          Kevin Dietz

________________________________
Support procedure: https://www.codify.com/lists/support
List address: [email protected]<mailto:[email protected]>
Subscribe: [email protected]<mailto:[email protected]>
Unsubscribe: [email protected]<mailto:[email protected]>
List FAQ: http://www.codify.com/lists/oztfs
Other lists you might want to join: http://www.codify.com/lists
________________________________
Support procedure: https://www.codify.com/lists/support
List address: [email protected]<mailto:[email protected]>
Subscribe: [email protected]<mailto:[email protected]>
Unsubscribe: [email protected]<mailto:[email protected]>
List FAQ: http://www.codify.com/lists/oztfs
Other lists you might want to join: http://www.codify.com/lists
________________________________
Support procedure: https://www.codify.com/lists/support
List address: [email protected]<mailto:[email protected]>
Subscribe: [email protected]<mailto:[email protected]>
Unsubscribe: [email protected]<mailto:[email protected]>
List FAQ: http://www.codify.com/lists/oztfs
Other lists you might want to join: http://www.codify.com/lists
--------------------------------------------------------------------------------
Support procedure: https://www.codify.com/lists/support
List address: [email protected]
Subscribe: [email protected]
Unsubscribe: [email protected]
List FAQ: http://www.codify.com/lists/oztfs
Other lists you might want to join: http://www.codify.com/lists

Reply via email to