[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: merging advice

From: Jeremy Mordkoff <jlm_at_ZeeVee.Com>
Date: Mon, 5 Oct 2009 14:15:11 -0400

From: Mark Phippard [mailto:markphip_at_gmail.com] Sent: Monday, October 05, 2009 12:23 PM
> On Mon, Oct 5, 2009 at 12:01 PM, Jeremy Mordkoff <jlm_at_zeevee.com> wrote:
> >> I would be concerned about all of those *.  That tells me you probably
> >> did something like use a depth=empty working copy to record mergeinfo.
> >>  The * tell Subversion the mergeinfo is not inheritable.  I'd probably
> >> just edit the property to remove the * and then do not do it that way
> >> again in the future.
> >
> > This is exactly what I did.
> >
> > Under /zcode/trunk we have about 9 subdirectories. Different projects use different subsets
> of these directories. When I was re-integrating the changes made in some branches, I only
> checked out the directories that were included in those checkouts. I goggled depth=none
> subversion merge and I did not see any warnings about this. Perhaps I did not read enough.
> >
> > At this moment, all branches have been re-integrated into trunk. Should I just remove all
> merge-info records across the board and start over using only fully populated work spaces?
> That will be a major pain in the rear since it will quadruple the space and time needed.
> In your case, it sounds like the feature is working as intended and I
> would not be worried.

Thanks. My big mistake was only looking at docs from tigris. Collabnet looks like a great resource.

I have now removed all mergeinfo properties from all subdirectories and now I am doing my merges only
in complete work spaces. Now when I commit, only the files in question and the root of our source tree
show as modified, instead of dozens and dozens of subdirectories.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-05 20:16:14 CEST

This is an archived mail posted to the Subversion Users mailing list.