Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > Stop creating mergeinfo on COPY (was: Problems reintegrating the issue-2843-dev branch)

subversion
Discussion topic

Hide all messages in topic

All messages in topic

Re: Stop creating mergeinfo on COPY (was: Problems reintegrating the issue-2843-dev branch)

Author Paul Burba <ptburba at gmail dot com>
Full name Paul Burba <ptburba at gmail dot com>
Date 2008-11-13 13:11:58 PST
Message On Wed, Nov 12, 2008 at 10:46 AM, Paul Burba <ptburba at gmail dot com> wrote:
> On Wed, Nov 12, 2008 at 10:01 AM, Mark Phippard <markphip at gmail dot com> wrote:
>> On Wed, Nov 12, 2008 at 9:59 AM, C. Michael Pilato <cmpilato at collab dot net> wrote:
>>> Mark Phippard wrote:
>>>> On Fri, Nov 7, 2008 at 7:10 PM, Paul Burba <ptburba at gmail dot com> wrote:
>>>>
>>>>> REALLY FIXING THE PROBLEM:
>>>>>
>>>>> Stopping all the WC-to-WC production of needless explicit mergeinfo
>>>>> would go a longggg way to avoiding this, but that doesn't help those
>>>>> (including us) with lots of historical subtree mergeinfo. More and
>>>>> more I think that copy and move (all, not just WC-to-WC) should never
>>>>> produce mergeinfo on the destination *unless* the source has it. It
>>>>> can't be worse than what we deal with now...
>>>>
>>>> I propose we just do this ... now. Let's just rip this code out of WC
>>>> to WC copy. Do not create mergeinfo when copying stuff. Forget about
>>>> making it smarter, let's just stop doing it. The problems we have
>>>> created by doing this are far worse than the theoretical problems we
>>>> could prevent by getting it right.
>>>>
>>>> Ripping this out will make our product better now and reduce user
>>>> frustration. If the theoretical problems turn into real problems and
>>>> if someone is motivated enough to put this code back then they can do
>>>> so in a way that gets it right.
>>>>
>>>> Let's stop the madness. If this one feature had not been put into
>>>> 1.5, then most of the problems relating to mergeinfo handling we
>>>> complain about would not even exist.
>>>
>>> At the risk of having you show up on my doorstep in a few hours wielding a
>>> battle axe, I'd suggest:
>>>
>>> 1. making 'svn copy WC WC' be mergeinfo-ignorant,
>>> 2. having that type of invocation print a warning about the fact
>>> that mergeinfo wasn't honored, and
>>> 3. add -g as the flag to calculate mergeinfo *with full repository
>>> access*?
>>
>> My only objection is that we have said this at least 100 times now. I
>> am saying lets do #1 .. today. If someone cares enough to do #2 and 3
>> it will get done.
>
> Nothing but +1s on #1, so I am going to do this, and soon, unless
> someone raises an objection.

Done r34184. The destination of a WC-to-WC copy/move no longer gets
explicit mergeinfo unless the source had it already.

Paul

Paul

Re: Stop creating mergeinfo on COPY (was: Problems reintegrating the issue-2843-dev branch)

Author Paul Burba <ptburba at gmail dot com>
Full name Paul Burba <ptburba at gmail dot com>
Date 2008-11-12 07:46:32 PST
Message On Wed, Nov 12, 2008 at 10:01 AM, Mark Phippard <markphip at gmail dot com> wrote:
> On Wed, Nov 12, 2008 at 9:59 AM, C. Michael Pilato <cmpilato at collab dot net> wrote:
>> Mark Phippard wrote:
>>> On Fri, Nov 7, 2008 at 7:10 PM, Paul Burba <ptburba at gmail dot com> wrote:
>>>
>>>> REALLY FIXING THE PROBLEM:
>>>>
>>>> Stopping all the WC-to-WC production of needless explicit mergeinfo
>>>> would go a longggg way to avoiding this, but that doesn't help those
>>>> (including us) with lots of historical subtree mergeinfo. More and
>>>> more I think that copy and move (all, not just WC-to-WC) should never
>>>> produce mergeinfo on the destination *unless* the source has it. It
>>>> can't be worse than what we deal with now...
>>>
>>> I propose we just do this ... now. Let's just rip this code out of WC
>>> to WC copy. Do not create mergeinfo when copying stuff. Forget about
>>> making it smarter, let's just stop doing it. The problems we have
>>> created by doing this are far worse than the theoretical problems we
>>> could prevent by getting it right.
>>>
>>> Ripping this out will make our product better now and reduce user
>>> frustration. If the theoretical problems turn into real problems and
>>> if someone is motivated enough to put this code back then they can do
>>> so in a way that gets it right.
>>>
>>> Let's stop the madness. If this one feature had not been put into
>>> 1.5, then most of the problems relating to mergeinfo handling we
>>> complain about would not even exist.
>>
>> At the risk of having you show up on my doorstep in a few hours wielding a
>> battle axe, I'd suggest:
>>
>> 1. making 'svn copy WC WC' be mergeinfo-ignorant,
>> 2. having that type of invocation print a warning about the fact
>> that mergeinfo wasn't honored, and
>> 3. add -g as the flag to calculate mergeinfo *with full repository
>> access*?
>
> My only objection is that we have said this at least 100 times now. I
> am saying lets do #1 .. today. If someone cares enough to do #2 and 3
> it will get done.

Nothing but +1s on #1, so I am going to do this, and soon, unless
someone raises an objection.

Re #3, so this would be the equivalent of a REPOS-to-WC copy right?
Unfortunately that is often just as ugly as the WC-to-WC copy. Taking
our own trunk as an example, there is some explicit mergeinfo on
subversion/libsvn_subr:

C:\SVN\src-trunk-3>svn pg svn:mergeinfo -Rv subversion\libsvn_subr
Properties on 'subversion\libsvn_subr':
  svn:mergeinfo
    /branches/1.5.x-r302​15/subversion/libsvn​_subr:30238
    /branches/bdb-revers​e-deltas/subversion/​libsvn_subr:31976-32​455
    /branches/diff-callb​acks3/subversion/lib​svn_subr:29985-30687​
    /branches/dont-save-​plaintext-passwords-​by-default/subversio​n/libsvn_subr:30654-​31044
    /branches/double-del​ete/subversion/libsv​n_subr:30437-32896
    /branches/file-exter​nals/subversion/libs​vn_subr:31705-33228
    /branches/fs-rep-sha​ring/subversion/libs​vn_subr:28962-33729
    /branches/gnome-keyr​ing/subversion/libsv​n_subr:30484-31336
    /branches/in-memory-​cache/subversion/lib​svn_subr:29755-31378​
    /branches/issue-2843​-dev/subversion/libs​vn_subr:31358-34105
    /branches/issue-3000​/subversion/libsvn_s​ubr:31639,31642-3164​5,31647-31652,31654,​31660
    /branches/issue-3067​-deleted-subtrees/su​bversion/libsvn_subr​:33301-34010
    /branches/issue-3220​-dev/subversion/libs​vn_subr:32136-32152
    /branches/kwallet/su​bversion/libsvn_subr​:30711-31240
    /branches/log-g-perf​ormance/subversion/l​ibsvn_subr:30867-309​58
    /branches/reintegrat​e-improvements/subve​rsion/libsvn_subr:33​779-34090
    /branches/svn-mergei​nfo-enhancements/sub​version/libsvn_subr:​30045-30214
    /branches/svnpatch-d​iff/subversion/libsv​n_subr:31831,31912
    /branches/svnserve-l​ogging/subversion/li​bsvn_subr:29754-3081​9
    /branches/tc-merge-n​otify/subversion/lib​svn_subr:33943-33988​
    /branches/tree-confl​icts/subversion/libs​vn_subr:28217-33080
    /branches/tree-confl​icts-notify/subversi​on/libsvn_subr:33852​-33934

Let's make a WC-to-WC copy of one of libsvn_subr's children with no
explicit mergeinfo:

C:\SVN\src-trunk-3>svn copy subversion\libsvn_subr\auth.c
subversion\libsvn_s​ubr\auth_wc_to_wc_c​opy.c
A subversion\libsvn_s​ubr\auth_wc_to_wc_c​opy.c

As this WC is at a uniform revision the newly added file get's
explicit mergeinfo equal to what its copy source inherited:

C:\SVN\src-trunk-3>svn pg svn:mergeinfo -v
subversion\libsvn_s​ubr\auth_wc_to_wc_c​opy.c
Properties on 'subversion\libsvn_​subr\auth_wc_to_wc_​copy.c':
  svn:mergeinfo
    /branches/1.5.x-r302​15/subversion/libsvn​_subr/auth.c:30238
    /branches/bdb-revers​e-deltas/subversion/​libsvn_subr/auth.c:3​1976-32455
    /branches/diff-callb​acks3/subversion/lib​svn_subr/auth.c:2998​5-30687
    /branches/dont-save-​plaintext-passwords-​by-default/subversio​n/libsvn_subr/auth.c​:30654-31044
    /branches/double-del​ete/subversion/libsv​n_subr/auth.c:30437-​32896
    /branches/file-exter​nals/subversion/libs​vn_subr/auth.c:31705​-33228
    /branches/fs-rep-sha​ring/subversion/libs​vn_subr/auth.c:28962​-33729
    /branches/gnome-keyr​ing/subversion/libsv​n_subr/auth.c:30484-​31336
    /branches/in-memory-​cache/subversion/lib​svn_subr/auth.c:2975​5-31378
    /branches/issue-2843​-dev/subversion/libs​vn_subr/auth.c:31358​-34105
    /branches/issue-3000​/subversion/libsvn_s​ubr/auth.c:31639,316​42-31645,31647-31652​,31654,31660
    /branches/issue-3067​-deleted-subtrees/su​bversion/libsvn_subr​/auth.c:33301-34010
    /branches/issue-3220​-dev/subversion/libs​vn_subr/auth.c:32136​-32152
    /branches/kwallet/su​bversion/libsvn_subr​/auth.c:30711-31240
    /branches/log-g-perf​ormance/subversion/l​ibsvn_subr/auth.c:30​867-30958
    /branches/reintegrat​e-improvements/subve​rsion/libsvn_subr/au​th.c:33779-34090
    /branches/svn-mergei​nfo-enhancements/sub​version/libsvn_subr/​auth.c:30045-30214
    /branches/svnpatch-d​iff/subversion/libsv​n_subr/auth.c:31831,​31912
    /branches/svnserve-l​ogging/subversion/li​bsvn_subr/auth.c:297​54-30819
    /branches/tc-merge-n​otify/subversion/lib​svn_subr/auth.c:3394​3-33988
    /branches/tree-confl​icts/subversion/libs​vn_subr/auth.c:28217​-33080
    /branches/tree-confl​icts-notify/subversi​on/libsvn_subr/auth.​c:33852-33934

Now do a REPOS-to-WC copy of the same file:

C:\SVN\src-trunk-3>svn copy
http://svn.collab.ne​t/repos/svn/trunk/su​bversion/libsvn_subr​/auth.c
subversion\libsvn_s​ubr\auth_repos_to_w​c_copy.c
A subversion\libsvn_s​ubr\auth_repos_to_w​c_copy.c

It still gets the same explicit mergeinfo!

C:\SVN\src-trunk-3>svn pg svn:mergeinfo -v
subversion\libsvn_s​ubr\auth_repos_to_w​c_copy.c
Properties on 'subversion\libsvn_​subr\auth_repos_to_​wc_copy.c':
  svn:mergeinfo
    /branches/1.5.x-r302​15/subversion/libsvn​_subr/auth.c:30238
    /branches/bdb-revers​e-deltas/subversion/​libsvn_subr/auth.c:3​1976-32455
    /branches/diff-callb​acks3/subversion/lib​svn_subr/auth.c:2998​5-30687
    /branches/dont-save-​plaintext-passwords-​by-default/subversio​n/libsvn_subr/auth.c​:30654-31044
    /branches/double-del​ete/subversion/libsv​n_subr/auth.c:30437-​32896
    /branches/file-exter​nals/subversion/libs​vn_subr/auth.c:31705​-33228
    /branches/fs-rep-sha​ring/subversion/libs​vn_subr/auth.c:28962​-33729
    /branches/gnome-keyr​ing/subversion/libsv​n_subr/auth.c:30484-​31336
    /branches/in-memory-​cache/subversion/lib​svn_subr/auth.c:2975​5-31378
    /branches/issue-2843​-dev/subversion/libs​vn_subr/auth.c:31358​-34105
    /branches/issue-3000​/subversion/libsvn_s​ubr/auth.c:31639,316​42-31645,31647-31652​,31654,31660
    /branches/issue-3067​-deleted-subtrees/su​bversion/libsvn_subr​/auth.c:33301-34010
    /branches/issue-3220​-dev/subversion/libs​vn_subr/auth.c:32136​-32152
    /branches/kwallet/su​bversion/libsvn_subr​/auth.c:30711-31240
    /branches/log-g-perf​ormance/subversion/l​ibsvn_subr/auth.c:30​867-30958
    /branches/reintegrat​e-improvements/subve​rsion/libsvn_subr/au​th.c:33779-34090
    /branches/svn-mergei​nfo-enhancements/sub​version/libsvn_subr/​auth.c:30045-30214
    /branches/svnpatch-d​iff/subversion/libsv​n_subr/auth.c:31831,​31912
    /branches/svnserve-l​ogging/subversion/li​bsvn_subr/auth.c:297​54-30819
    /branches/tc-merge-n​otify/subversion/lib​svn_subr/auth.c:3394​3-33988
    /branches/tree-confl​icts/subversion/libs​vn_subr/auth.c:28217​-33080
    /branches/tree-confl​icts-notify/subversi​on/libsvn_subr/auth.​c:33852-33934

So in this common case, -g actually gives us the same old result. Not
to say we shouldn't implement copy/move -g, but it might be a mistake
to advertise it as "gives the correct results".

Paul "I love mergeinfo so much I want to marry it. So then I can
divorce it an have a bitter custody battle over our kids, psi, omega,
gamma, and beta" Burba

Re: Stop creating mergeinfo on COPY (was: Problems reintegrating the issue-2843-dev branch)

Author Ivan Zhakov <ivan at visualsvn dot com>
Full name Ivan Zhakov <ivan at visualsvn dot com>
Date 2008-11-12 07:06:24 PST
Message On Wed, Nov 12, 2008 at 5:50 PM, Mark Phippard <markphip at gmail dot com> wrote:
> On Fri, Nov 7, 2008 at 7:10 PM, Paul Burba <ptburba at gmail dot com> wrote:
>
>> REALLY FIXING THE PROBLEM:
>>
>> Stopping all the WC-to-WC production of needless explicit mergeinfo
>> would go a longggg way to avoiding this, but that doesn't help those
>> (including us) with lots of historical subtree mergeinfo. More and
>> more I think that copy and move (all, not just WC-to-WC) should never
>> produce mergeinfo on the destination *unless* the source has it. It
>> can't be worse than what we deal with now...
>
> I propose we just do this ... now. Let's just rip this code out of WC
> to WC copy. Do not create mergeinfo when copying stuff. Forget about
> making it smarter, let's just stop doing it. The problems we have
> created by doing this are far worse than the theoretical problems we
> could prevent by getting it right.
>
+1! This will be significant improvements for a LOT of users. Just had
conversion with one Subversion user ended with automatically cleanup
ALL svn:mergeinfo excluding only top level trunk directory.

--
Ivan Zhakov
VisualSVN Team

Re: Stop creating mergeinfo on COPY (was: Problems reintegrating the issue-2843-dev branch)

Author sdanil
Full name Danil Shopyrin
Date 2008-11-12 07:03:32 PST
Message > Let's stop the madness. If this one feature had not been put into
> 1.5, then most of the problems relating to mergeinfo handling we
> complain about would not even exist.

+1

--
With best regards,
Danil Shopyrin
VisualSVN Team

Re: Stop creating mergeinfo on COPY (was: Problems reintegrating the issue-2843-dev branch)

Author Mark Phippard <markphip at gmail dot com>
Full name Mark Phippard <markphip at gmail dot com>
Date 2008-11-12 07:01:30 PST
Message On Wed, Nov 12, 2008 at 9:59 AM, C. Michael Pilato <cmpilato at collab dot net> wrote:
> Mark Phippard wrote:
>> On Fri, Nov 7, 2008 at 7:10 PM, Paul Burba <ptburba at gmail dot com> wrote:
>>
>>> REALLY FIXING THE PROBLEM:
>>>
>>> Stopping all the WC-to-WC production of needless explicit mergeinfo
>>> would go a longggg way to avoiding this, but that doesn't help those
>>> (including us) with lots of historical subtree mergeinfo. More and
>>> more I think that copy and move (all, not just WC-to-WC) should never
>>> produce mergeinfo on the destination *unless* the source has it. It
>>> can't be worse than what we deal with now...
>>
>> I propose we just do this ... now. Let's just rip this code out of WC
>> to WC copy. Do not create mergeinfo when copying stuff. Forget about
>> making it smarter, let's just stop doing it. The problems we have
>> created by doing this are far worse than the theoretical problems we
>> could prevent by getting it right.
>>
>> Ripping this out will make our product better now and reduce user
>> frustration. If the theoretical problems turn into real problems and
>> if someone is motivated enough to put this code back then they can do
>> so in a way that gets it right.
>>
>> Let's stop the madness. If this one feature had not been put into
>> 1.5, then most of the problems relating to mergeinfo handling we
>> complain about would not even exist.
>
> At the risk of having you show up on my doorstep in a few hours wielding a
> battle axe, I'd suggest:
>
> 1. making 'svn copy WC WC' be mergeinfo-ignorant,
> 2. having that type of invocation print a warning about the fact
> that mergeinfo wasn't honored, and
> 3. add -g as the flag to calculate mergeinfo *with full repository
> access*?

My only objection is that we have said this at least 100 times now. I
am saying lets do #1 .. today. If someone cares enough to do #2 and 3
it will get done.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Stop creating mergeinfo on COPY (was: Problems reintegrating the issue-2843-dev branch)

Author cmpilato
Full name C. Michael Pilato
Date 2008-11-12 06:59:58 PST
Message Mark Phippard wrote:
> On Fri, Nov 7, 2008 at 7:10 PM, Paul Burba <ptburba at gmail dot com> wrote:
>
>> REALLY FIXING THE PROBLEM:
>>
>> Stopping all the WC-to-WC production of needless explicit mergeinfo
>> would go a longggg way to avoiding this, but that doesn't help those
>> (including us) with lots of historical subtree mergeinfo. More and
>> more I think that copy and move (all, not just WC-to-WC) should never
>> produce mergeinfo on the destination *unless* the source has it. It
>> can't be worse than what we deal with now...
>
> I propose we just do this ... now. Let's just rip this code out of WC
> to WC copy. Do not create mergeinfo when copying stuff. Forget about
> making it smarter, let's just stop doing it. The problems we have
> created by doing this are far worse than the theoretical problems we
> could prevent by getting it right.
>
> Ripping this out will make our product better now and reduce user
> frustration. If the theoretical problems turn into real problems and
> if someone is motivated enough to put this code back then they can do
> so in a way that gets it right.
>
> Let's stop the madness. If this one feature had not been put into
> 1.5, then most of the problems relating to mergeinfo handling we
> complain about would not even exist.

At the risk of having you show up on my doorstep in a few hours wielding a
battle axe, I'd suggest:

   1. making 'svn copy WC WC' be mergeinfo-ignorant,
   2. having that type of invocation print a warning about the fact
      that mergeinfo wasn't honored, and
   3. add -g as the flag to calculate mergeinfo *with full repository
      access*?

--
C. Michael Pilato <cmpilato at collab dot net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Attachments

Stop creating mergeinfo on COPY (was: Problems reintegrating the issue-2843-dev branch)

Author Mark Phippard <markphip at gmail dot com>
Full name Mark Phippard <markphip at gmail dot com>
Date 2008-11-12 06:50:14 PST
Message On Fri, Nov 7, 2008 at 7:10 PM, Paul Burba <ptburba at gmail dot com> wrote:

> REALLY FIXING THE PROBLEM:
>
> Stopping all the WC-to-WC production of needless explicit mergeinfo
> would go a longggg way to avoiding this, but that doesn't help those
> (including us) with lots of historical subtree mergeinfo. More and
> more I think that copy and move (all, not just WC-to-WC) should never
> produce mergeinfo on the destination *unless* the source has it. It
> can't be worse than what we deal with now...

I propose we just do this ... now. Let's just rip this code out of WC
to WC copy. Do not create mergeinfo when copying stuff. Forget about
making it smarter, let's just stop doing it. The problems we have
created by doing this are far worse than the theoretical problems we
could prevent by getting it right.

Ripping this out will make our product better now and reduce user
frustration. If the theoretical problems turn into real problems and
if someone is motivated enough to put this code back then they can do
so in a way that gets it right.

Let's stop the madness. If this one feature had not been put into
1.5, then most of the problems relating to mergeinfo handling we
complain about would not even exist.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/
Messages per page: