RE: What causes a conflict question

> Thanks all for the suggestions
>
> To make a correction - let me add some lines to my original post
> (unquoted)
>
>
> > I'm sorry, I don't see this in the documentation or a prior post
> >
> > Say you have a file in the trunk with these 2 lines
> >
> > aa
> > bb
> >
> > Developers Y and Z create new, separate branches from this.
> >
> > While developer Z is still working in their branch, developer Y
> commits the file into the trunk. it is now:
> >
> > aa qqqq
> > bb
> >
> > Later, developer Z commits this file to their branch as follows:
> >
> > aa
> > bb
> > cc
>
> Then developer Z switches to the trunk and merges in their
> revision. The option "Merge a Range of Revisions" is selected
>
> >
> > As I'm experiencing, the "qqqq" will be gone upon developer Z's
> commit. Despite the fact that developer Z never knew of the
> existence of the "qqqq" (nor deleted it), there is no conflict
> when developer Z makes a commit. It is the responsible of
> developer Z to ensure that they're not overwriting any thing that
> was committed to the file after the branch was created
>
>
> > Is this correct?
>
> Does anyone have any suggestions to avoid this? Another developer
> I work with said to choose "Reintegrate a branch", which a poster
> here said to avoid

When you merge data should not be lost, assuming if it is down properly. If a user just copies his version from his branch into the trunk and commits it, yes you would use the qqqq... but if that dev does a merge the qqqq should not be lost... at the least it would show as a conflict and the dev would have to make a conscious decisions as to which line to keep, his or the one from the repository.

People tend to avoid that which they do not understand. Doing an re-integration depends on your branching strategy. Generally you will use re-integrate for feature branches while for a release branch you would not use re-integrate. I suggest you read the red book on branching strategies... it is quite informative.

We use both release/version branches and feature branches. Our release branches are always merged from lowest version to highest. So, if a fix is made in 6.5.5 and we have a 6.5.6 and a 7.0.0 branch we would merge from 6.5.5 to 6.5.6 and then from 6.5.6 to 7.0.0.

However, if we are working on a new "big" feature (more than one sprint long) we will create a feature branch. The feature branch is kept up to date on a weekly (or more often) time frame. Once the feature is complete the branch is re-integrated into the version branch and then the feature branch is deleted. This strategy has been working well for us... much better than trying to remember what version "trunk" is and dealing with cyclical merges, etc.

BOb

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2704023

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-02-14 23:20:07 CET