You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andrey Paramonov <pa...@acdlabs.ru> on 2011/10/18 09:40:37 UTC
Merge strategies?
With Subversion 1.7 released, our company is considering more active use
of merging with the help of svn:mergeinfo. Upon reading some
tutorials/articles and thinking a bit, I can see how awareness of
svn:mergeinfo improves certain workflows, but also I see some potential
problems. I'd like to hear your comments and suggestions on the following.
We have 1 large repository of the following layout (not exactly, but
quite isomorphic):
trunk/
release/
1.0/
1.1/
2.0/
...
branches/
We have ~30 programmers, about 50 commits go to the trunk daily, from
which about one half goes to at least one release branch. Some
programmers also use private branches. Till now, most merges were done
with --ignore-ancestry (because of slowness of svn:mergeinfo in <=1.6,
among other reasons). Now we want to encourage the usage of merge
tracking. Here is the description of used workflows and my
considerations on pros and cons of merge tracking:
1) Feature branches.
User creates private branch, works on her task while merging from trunk
periodically, then reintegrates the changes to the trunk.
Pro: merge tracking allows to sync from trunk with great ease.
Cons: nothing I can think of (svn:mergeinfo is compact and consolidated,
no conflicts possible in svn:mergeinfo)
2) Merge from trunk (cherrypicking).
User works on trunk, then merges some changes to one or more branches.
Pro: svn:mergeinfo allows to see what has been merged to particular
release branch, and what wasn't.
Cons: svn:mergeinfo soon becomes bloated (even single task commits
almost never make a contiguous range), svn:mergeinfo is scattered (some
users only have access to a subtree of a release branch), svn:mergeinfo
conflicts seem very possible (many users can do merge at the same time).
3) Merge from release branch.
User debugs and fixes a bug in a release branch, then merges the bugfix
to trunk.
Pro: nothing I can think of (except no need to type --ignore-ancestry ;-)
Cons: svn:mergeinfo soon becomes bloated and scattered, svn:mergeinfo
conflicts seem very possible, very confusing svn:mergeinfo for release
branches (it might tell someone merged code from one release branch to
another, however in reality you just cut the branch after merge to trunk).
I now tend to think that merge tracking is definitely a win for 1), but
would introduce many problems for 2) and 3), without gaining us much
value. What confuses people most now is the scattered svn:mergeinfo
("Oh, why that dir has modified status, my merge shouldn't have changed
it!"). But people can be persuaded that it's "Ok". What bothers me more
is svn:mergeinfo bloated (slowness) and conflicting (major annoyance).
Maybe I'm missing something?
Your comments greatly appreciated,
Andrey Paramonov
RE: Merge strategies?
Posted by Bob Archer <Bo...@amsi.com>.
> On 21.10.2011 17:32, Bob Archer wrote:
> >> Hm, it looks like you should have really huge svn:mergeinfo in your
> >> latest VersionX. Did you notice any slowdown?
> >
> > I'm not sure I would call it huge. Here is the mergeinfo on our newest in
> dev version path root:
> >
> > /Product/branches/B_01490:39129-39612
> > /Product/branches/v6.0.0.1:3913-4250
> > /Product/branches/v6.0.1-BOD:29569-30097
> > /Product/branches/v6.5.1 B-06016 and B-06017:38413-38505
> > /Product/branches/v6.5.2:39097-39128
> > /Product/trunk:39633-40031
> > /Product/v6.5.1:40032-42329
> > /Product/v6.5.2:40827-45486
> > /Product/v6.5.3:42165-45488
> > /Product/v6.5.4:44500-46506
> > /Product/v7.0.1:45519-46535
> > /Product/v7.0.2:46560-47506
> > /Product/v7.1.0:47440-48031
> >
> > (of course product isn't actually the product name)
> >
> > Keep in mind... whenever you merge the merge info is updated. The high
> number of the range is changed rather than a new line being added. So each
> merge line there from say 7.1.0 represents multiple merges (I think three at
> this point). This also includes some merge info from back when we still used
> trunk and release branches. As you see we do very few feature branches.
> >
> > No, I don't notice any slowdown.
> >
> >> Also, as you usually merge upstream, I presume you could encounter
> >> svn:mergeinfo conflict when 2 users merge i.e. into latest VersionX
> >> simultaneously. Has it ever happened to you?
> >
> > No, we have a weekly task to merge and usually one person does it.
> However, I don't see how there could be a conflict since it would be caught
> as a conflict at commit time if two people tried to commit the same merge.
>
> Yes, I'd like to avoid this "conflict at commit time". Such things tend to
> confuse users big time.
This strikes me as a training issue. Even on an update there is a possibility that a merge conflict will occur. Your users need to understand them and know how to deal with them for them to effectively use the system.
BOb
>
> >> From what I read, I see you use mergeinfo to prevent accidental
> >> cyclic merges. Do you use it for something else? So far I don't
> >> understand how the mergeinfo about upstream merges could be really
> useful.
> >
> > No, our merge policy is to prevent cyclic merges not the mergeinfo. The
> mergeinfo is used for exactly what it is meant for. To keep track of previous
> merges so they won't be duplicated. Prior to merginfo (was it added in 1.5 I
> guess?) we had to record that info in our commit message and find it when
> the next merge was done. Now svn does that record keeping for us.
> >
>
> Ah, I now see that you basically merge everything, not cherry-pick. It makes
> sense for your setup. I now see that we could also do this (in rather rare
> cases when we merge upstream) if we have mergeinfo filled for our release
> branches.
>
> Thank you for sharing your experience,
> Andrey Paramonov
Re: Merge strategies?
Posted by Andrey Paramonov <pa...@acdlabs.ru>.
On 21.10.2011 17:32, Bob Archer wrote:
>> Hm, it looks like you should have really huge svn:mergeinfo in your latest
>> VersionX. Did you notice any slowdown?
>
> I'm not sure I would call it huge. Here is the mergeinfo on our newest in dev version path root:
>
> /Product/branches/B_01490:39129-39612
> /Product/branches/v6.0.0.1:3913-4250
> /Product/branches/v6.0.1-BOD:29569-30097
> /Product/branches/v6.5.1 B-06016 and B-06017:38413-38505
> /Product/branches/v6.5.2:39097-39128
> /Product/trunk:39633-40031
> /Product/v6.5.1:40032-42329
> /Product/v6.5.2:40827-45486
> /Product/v6.5.3:42165-45488
> /Product/v6.5.4:44500-46506
> /Product/v7.0.1:45519-46535
> /Product/v7.0.2:46560-47506
> /Product/v7.1.0:47440-48031
>
> (of course product isn't actually the product name)
>
> Keep in mind... whenever you merge the merge info is updated. The high number of the range is changed rather than a new line being added. So each merge line there from say 7.1.0 represents multiple merges (I think three at this point). This also includes some merge info from back when we still used trunk and release branches. As you see we do very few feature branches.
>
> No, I don't notice any slowdown.
>
>> Also, as you usually merge upstream, I presume you could encounter
>> svn:mergeinfo conflict when 2 users merge i.e. into latest VersionX
>> simultaneously. Has it ever happened to you?
>
> No, we have a weekly task to merge and usually one person does it. However, I don't see how there could be a conflict since it would be caught as a conflict at commit time if two people tried to commit the same merge.
Yes, I'd like to avoid this "conflict at commit time". Such things tend
to confuse users big time.
>> From what I read, I see you use mergeinfo to prevent accidental cyclic
>> merges. Do you use it for something else? So far I don't understand how the
>> mergeinfo about upstream merges could be really useful.
>
> No, our merge policy is to prevent cyclic merges not the mergeinfo. The mergeinfo is used for exactly what it is meant for. To keep track of previous merges so they won't be duplicated. Prior to merginfo (was it added in 1.5 I guess?) we had to record that info in our commit message and find it when the next merge was done. Now svn does that record keeping for us.
>
Ah, I now see that you basically merge everything, not cherry-pick. It
makes sense for your setup. I now see that we could also do this (in
rather rare cases when we merge upstream) if we have mergeinfo filled
for our release branches.
Thank you for sharing your experience,
Andrey Paramonov
RE: Merge strategies?
Posted by Bob Archer <Bo...@amsi.com>.
> On 21.10.2011 1:56, Bob Archer wrote:
> >> 1) Do you usually merge upstream or downstream?
> >> 2) Do you set mergeinfo when merging downstream?
> >> 3) Do you set mergeinfo when merging upstream?
> >> 4) Do you set mergeinfo when merging from feature branch?
> >>
> >
> > 1) We generally only merge up version. A fix is made in the earliest version
> path where we are going to release it and then merged up to the newer
> versions. There may be a case where we made a change in a version and
> needed it in the old version. I'm not sure that happened yet. I assume if it is
> ever don I would do a record-only merge of the rev in the next version's path
> so it won't conflict in future merges.
> >
> > 2, 3 and 4) We always use mergeinfo. (svn sets it automatically)
> >
> > BOb
>
> Hm, it looks like you should have really huge svn:mergeinfo in your latest
> VersionX. Did you notice any slowdown?
I'm not sure I would call it huge. Here is the mergeinfo on our newest in dev version path root:
/Product/branches/B_01490:39129-39612
/Product/branches/v6.0.0.1:3913-4250
/Product/branches/v6.0.1-BOD:29569-30097
/Product/branches/v6.5.1 B-06016 and B-06017:38413-38505
/Product/branches/v6.5.2:39097-39128
/Product/trunk:39633-40031
/Product/v6.5.1:40032-42329
/Product/v6.5.2:40827-45486
/Product/v6.5.3:42165-45488
/Product/v6.5.4:44500-46506
/Product/v7.0.1:45519-46535
/Product/v7.0.2:46560-47506
/Product/v7.1.0:47440-48031
(of course product isn't actually the product name)
Keep in mind... whenever you merge the merge info is updated. The high number of the range is changed rather than a new line being added. So each merge line there from say 7.1.0 represents multiple merges (I think three at this point). This also includes some merge info from back when we still used trunk and release branches. As you see we do very few feature branches.
No, I don't notice any slowdown.
> Also, as you usually merge upstream, I presume you could encounter
> svn:mergeinfo conflict when 2 users merge i.e. into latest VersionX
> simultaneously. Has it ever happened to you?
No, we have a weekly task to merge and usually one person does it. However, I don't see how there could be a conflict since it would be caught as a conflict at commit time if two people tried to commit the same merge.
> From what I read, I see you use mergeinfo to prevent accidental cyclic
> merges. Do you use it for something else? So far I don't understand how the
> mergeinfo about upstream merges could be really useful.
No, our merge policy is to prevent cyclic merges not the mergeinfo. The mergeinfo is used for exactly what it is meant for. To keep track of previous merges so they won't be duplicated. Prior to merginfo (was it added in 1.5 I guess?) we had to record that info in our commit message and find it when the next merge was done. Now svn does that record keeping for us.
> Thank you for your valuable comments,
> Andrey Paramonov
Hope it helps,
BOb
Re: Merge strategies?
Posted by Andrey Paramonov <pa...@acdlabs.ru>.
On 21.10.2011 1:56, Bob Archer wrote:
>> 1) Do you usually merge upstream or downstream?
>> 2) Do you set mergeinfo when merging downstream?
>> 3) Do you set mergeinfo when merging upstream?
>> 4) Do you set mergeinfo when merging from feature branch?
>>
>
> 1) We generally only merge up version. A fix is made in the earliest version path where we are going to release it and then merged up to the newer versions. There may be a case where we made a change in a version and needed it in the old version. I'm not sure that happened yet. I assume if it is ever don I would do a record-only merge of the rev in the next version's path so it won't conflict in future merges.
>
> 2, 3 and 4) We always use mergeinfo. (svn sets it automatically)
>
> BOb
Hm, it looks like you should have really huge svn:mergeinfo in your
latest VersionX. Did you notice any slowdown?
Also, as you usually merge upstream, I presume you could encounter
svn:mergeinfo conflict when 2 users merge i.e. into latest VersionX
simultaneously. Has it ever happened to you?
From what I read, I see you use mergeinfo to prevent accidental cyclic
merges. Do you use it for something else? So far I don't understand how
the mergeinfo about upstream merges could be really useful.
Thank you for your valuable comments,
Andrey Paramonov
RE: Merge strategies?
Posted by Bob Archer <Bo...@amsi.com>.
> On 20.10.2011 17:55, Bob Archer wrote:
> >> On 19.10.2011 14:00, Stefan Sperling wrote:
> >>> On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote:
> >>>> What about my other fears, bloated svn:mergeinfo
> >>>
> >>> The entire svn:mergeinfo property is stored in RAM and parsed from
> >>> string form into a data structure (nested hash table) before it is used.
> >>> With modern hardware, you'd have to hit svn:mergeinfo sizes that go
> >>> into hundreds of megabytes before you'll notice any slowdown.
> >>>
> >>
> >> Hm, but this parsing occurs on every invocation of "svn.exe", or I'm
> >> missing something?
> >>
> >>>> and svn:mergeinfo conflicts?
> >>>
> >>> Have you ever seen a mergeinfo conflict? I haven't.
> >>>
> >>
> >> I haven't, too, because everyone uses --ignore-ancestry here ;-)
> >
> > We've moved away from using trunk to simplify our merging and eliminate
> cyclic merges.
> >
> > We have something like:
> >
> > Project
> > /Version1
> > /Version2
> > /Branches
> > /Feature1
> > /Feature2
> > /Tags
> > /Release1
> > /Release2
> >
> > We release from the VersionX path. When we start on a new release a new
> VersionX path is created by copying (branching) from the previous version.
> Feature branches are created from a VersionX path then reintegrated when
> the features is complete. We only use feature branches for stuff that will
> take more than on sprint.
> >
> > The above has really helped the organization of our build server since we
> don't have to constantly wonder what version is in progress on trunk.
> >
> > If we fix an issue in a specific version those changes are merged up into
> each version as needed. We generally don't deal with more than 3 versions
> at a time so the "up merging" is rarely need beyond 2 merges.
> >
> > It's not perfect but it works much better for us than stable trunk, branch for
> release was working. And all the devs easily understand what it is what path
> when they browse the repo.
> >
> > BOb
>
> Thank you for your answer. A couple of questions:
>
> 1) Do you usually merge upstream or downstream?
> 2) Do you set mergeinfo when merging downstream?
> 3) Do you set mergeinfo when merging upstream?
> 4) Do you set mergeinfo when merging from feature branch?
>
1) We generally only merge up version. A fix is made in the earliest version path where we are going to release it and then merged up to the newer versions. There may be a case where we made a change in a version and needed it in the old version. I'm not sure that happened yet. I assume if it is ever don I would do a record-only merge of the rev in the next version's path so it won't conflict in future merges.
2, 3 and 4) We always use mergeinfo. (svn sets it automatically)
BOb
Re: Merge strategies?
Posted by Andrey Paramonov <pa...@acdlabs.ru>.
On 20.10.2011 17:55, Bob Archer wrote:
>> On 19.10.2011 14:00, Stefan Sperling wrote:
>>> On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote:
>>>> What about my other fears, bloated svn:mergeinfo
>>>
>>> The entire svn:mergeinfo property is stored in RAM and parsed from
>>> string form into a data structure (nested hash table) before it is used.
>>> With modern hardware, you'd have to hit svn:mergeinfo sizes that go
>>> into hundreds of megabytes before you'll notice any slowdown.
>>>
>>
>> Hm, but this parsing occurs on every invocation of "svn.exe", or I'm missing
>> something?
>>
>>>> and svn:mergeinfo conflicts?
>>>
>>> Have you ever seen a mergeinfo conflict? I haven't.
>>>
>>
>> I haven't, too, because everyone uses --ignore-ancestry here ;-)
>
> We've moved away from using trunk to simplify our merging and eliminate cyclic merges.
>
> We have something like:
>
> Project
> /Version1
> /Version2
> /Branches
> /Feature1
> /Feature2
> /Tags
> /Release1
> /Release2
>
> We release from the VersionX path. When we start on a new release a new VersionX path is created by copying (branching) from the previous version. Feature branches are created from a VersionX path then reintegrated when the features is complete. We only use feature branches for stuff that will take more than on sprint.
>
> The above has really helped the organization of our build server since we don't have to constantly wonder what version is in progress on trunk.
>
> If we fix an issue in a specific version those changes are merged up into each version as needed. We generally don't deal with more than 3 versions at a time so the "up merging" is rarely need beyond 2 merges.
>
> It's not perfect but it works much better for us than stable trunk, branch for release was working. And all the devs easily understand what it is what path when they browse the repo.
>
> BOb
Thank you for your answer. A couple of questions:
1) Do you usually merge upstream or downstream?
2) Do you set mergeinfo when merging downstream?
3) Do you set mergeinfo when merging upstream?
4) Do you set mergeinfo when merging from feature branch?
Best wishes,
Andrey Paramonov
RE: Merge strategies?
Posted by Bob Archer <Bo...@amsi.com>.
> On 19.10.2011 14:00, Stefan Sperling wrote:
> > On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote:
> >> What about my other fears, bloated svn:mergeinfo
> >
> > The entire svn:mergeinfo property is stored in RAM and parsed from
> > string form into a data structure (nested hash table) before it is used.
> > With modern hardware, you'd have to hit svn:mergeinfo sizes that go
> > into hundreds of megabytes before you'll notice any slowdown.
> >
>
> Hm, but this parsing occurs on every invocation of "svn.exe", or I'm missing
> something?
>
> >> and svn:mergeinfo conflicts?
> >
> > Have you ever seen a mergeinfo conflict? I haven't.
> >
>
> I haven't, too, because everyone uses --ignore-ancestry here ;-)
We've moved away from using trunk to simplify our merging and eliminate cyclic merges.
We have something like:
Project
/Version1
/Version2
/Branches
/Feature1
/Feature2
/Tags
/Release1
/Release2
We release from the VersionX path. When we start on a new release a new VersionX path is created by copying (branching) from the previous version. Feature branches are created from a VersionX path then reintegrated when the features is complete. We only use feature branches for stuff that will take more than on sprint.
The above has really helped the organization of our build server since we don't have to constantly wonder what version is in progress on trunk.
If we fix an issue in a specific version those changes are merged up into each version as needed. We generally don't deal with more than 3 versions at a time so the "up merging" is rarely need beyond 2 merges.
It's not perfect but it works much better for us than stable trunk, branch for release was working. And all the devs easily understand what it is what path when they browse the repo.
BOb
Re: Merge strategies?
Posted by Andrey Paramonov <pa...@acdlabs.ru>.
On 19.10.2011 14:00, Stefan Sperling wrote:
> On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote:
>> What about my other fears, bloated svn:mergeinfo
>
> The entire svn:mergeinfo property is stored in RAM and parsed from
> string form into a data structure (nested hash table) before it is used.
> With modern hardware, you'd have to hit svn:mergeinfo sizes that go
> into hundreds of megabytes before you'll notice any slowdown.
>
Hm, but this parsing occurs on every invocation of "svn.exe", or I'm
missing something?
>> and svn:mergeinfo conflicts?
>
> Have you ever seen a mergeinfo conflict? I haven't.
>
I haven't, too, because everyone uses --ignore-ancestry here ;-)
Thanks for your comments,
Andrey Paramonov
Re: Merge strategies?
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote:
> What about my other fears, bloated svn:mergeinfo
The entire svn:mergeinfo property is stored in RAM and parsed from
string form into a data structure (nested hash table) before it is used.
With modern hardware, you'd have to hit svn:mergeinfo sizes that go
into hundreds of megabytes before you'll notice any slowdown.
> and svn:mergeinfo conflicts?
Have you ever seen a mergeinfo conflict? I haven't.
Re: Merge strategies?
Posted by Andrey Paramonov <pa...@acdlabs.ru>.
On 19.10.2011 11:44, Johan Corveleyn wrote:
> On Wed, Oct 19, 2011 at 8:38 AM, Andrey Paramonov<pa...@acdlabs.ru> wrote:
>> On 18.10.2011 20:05, Daniel Shahaf wrote:
>>>
>>> Andrey Paramonov wrote on Tue, Oct 18, 2011 at 11:40:37 +0400:
>>>>
>>>> What confuses people most now is the scattered
>>>> svn:mergeinfo ("Oh, why that dir has modified status, my merge
>>>> shouldn't have changed it!").
>>>
>>> Isn't this particular issue fixed in 1.7?
>>
>> No, it's apparently not. What was fixed is svn:mergeinfo physical storage
>> format and location in working copy. On the contrary, the
>> inheritance/elision rules were not (cannot be?) changed. Basically,
>> everything said in
>> http://www.collab.net/community/subversion/articles/merge-info.html about
>> "pesky implementation details" remains valid.
>>
>> Consider the following example. Users typically merge to /release/1.0.1/.
>> Merge info is recorded to svn:mergeinfo of /release/1.0.1/. Now consider
>> someone merges once to /release/1.0.1/some/subdir/. Possible reasons:
>> 1) Her changes belong only to some/subdir/.
>> 2) She has checkout of just /release/1.0.1/some/subdir/, not the whole
>> /release/1.0.1/.
>> 3) She doesn't have access to /release/1.0.1/ at all, only to
>> /release/1.0.1/some/subdir/.
>>
>> Ok, now another user merges to /release/1.0.1/. Suppose his changes only
>> belong to another/dir. But he would see that /release/1.0.1/some/subdir/ has
>> modified flag! This is very confusing and hard to explain (I have tried).
>
> This precisely the behavior that should have been improved in 1.7 [1].
> So I'm surprised that it is not. You are testing this (the part with
> "now another user merges ...") with a 1.7 client, yes?
>
> [1] http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
>
Ah, I now tested a bit more thoroughly and I see that it's fixed indeed.
Very good, and sorry for the noise.
What about my other fears, bloated svn:mergeinfo and svn:mergeinfo
conflicts?
Best wishes,
Andrey Paramonov
Re: Merge strategies?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Oct 19, 2011 at 8:38 AM, Andrey Paramonov <pa...@acdlabs.ru> wrote:
> On 18.10.2011 20:05, Daniel Shahaf wrote:
>>
>> Andrey Paramonov wrote on Tue, Oct 18, 2011 at 11:40:37 +0400:
>>>
>>> What confuses people most now is the scattered
>>> svn:mergeinfo ("Oh, why that dir has modified status, my merge
>>> shouldn't have changed it!").
>>
>> Isn't this particular issue fixed in 1.7?
>
> No, it's apparently not. What was fixed is svn:mergeinfo physical storage
> format and location in working copy. On the contrary, the
> inheritance/elision rules were not (cannot be?) changed. Basically,
> everything said in
> http://www.collab.net/community/subversion/articles/merge-info.html about
> "pesky implementation details" remains valid.
>
> Consider the following example. Users typically merge to /release/1.0.1/.
> Merge info is recorded to svn:mergeinfo of /release/1.0.1/. Now consider
> someone merges once to /release/1.0.1/some/subdir/. Possible reasons:
> 1) Her changes belong only to some/subdir/.
> 2) She has checkout of just /release/1.0.1/some/subdir/, not the whole
> /release/1.0.1/.
> 3) She doesn't have access to /release/1.0.1/ at all, only to
> /release/1.0.1/some/subdir/.
>
> Ok, now another user merges to /release/1.0.1/. Suppose his changes only
> belong to another/dir. But he would see that /release/1.0.1/some/subdir/ has
> modified flag! This is very confusing and hard to explain (I have tried).
This precisely the behavior that should have been improved in 1.7 [1].
So I'm surprised that it is not. You are testing this (the part with
"now another user merges ...") with a 1.7 client, yes?
[1] http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
--
Johan
Re: Merge strategies?
Posted by Andrey Paramonov <pa...@acdlabs.ru>.
On 18.10.2011 20:05, Daniel Shahaf wrote:
> Andrey Paramonov wrote on Tue, Oct 18, 2011 at 11:40:37 +0400:
>> What confuses people most now is the scattered
>> svn:mergeinfo ("Oh, why that dir has modified status, my merge
>> shouldn't have changed it!").
>
> Isn't this particular issue fixed in 1.7?
No, it's apparently not. What was fixed is svn:mergeinfo physical
storage format and location in working copy. On the contrary, the
inheritance/elision rules were not (cannot be?) changed. Basically,
everything said in
http://www.collab.net/community/subversion/articles/merge-info.html
about "pesky implementation details" remains valid.
Consider the following example. Users typically merge to
/release/1.0.1/. Merge info is recorded to svn:mergeinfo of
/release/1.0.1/. Now consider someone merges once to
/release/1.0.1/some/subdir/. Possible reasons:
1) Her changes belong only to some/subdir/.
2) She has checkout of just /release/1.0.1/some/subdir/, not the whole
/release/1.0.1/.
3) She doesn't have access to /release/1.0.1/ at all, only to
/release/1.0.1/some/subdir/.
Ok, now another user merges to /release/1.0.1/. Suppose his changes only
belong to another/dir. But he would see that /release/1.0.1/some/subdir/
has modified flag! This is very confusing and hard to explain (I have
tried).
Any pointers on how to minimize this distraction greatly appreciated.
Best wishes,
Andrey Paramonov
Re: Merge strategies?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Andrey Paramonov wrote on Tue, Oct 18, 2011 at 11:40:37 +0400:
> What confuses people most now is the scattered
> svn:mergeinfo ("Oh, why that dir has modified status, my merge
> shouldn't have changed it!").
Isn't this particular issue fixed in 1.7?