You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Danil Shopyrin <da...@visualsvn.com> on 2008/08/27 13:00:26 UTC
Useless explicit mergeinfo records
Hi!
I'm trying to figure out how merge tracking should work to be more
usable (at least for me and my friends). For now, we don't use merge
tracking because it just doesn't work for us :) Moreover, some of our
day-by-day practices are partially broken. After migrating to
Subversion 1.5 merges became (very!) slow and unpredictable.
There are (for now) three problems I found. Please let me know if they
are bugs or features :)
1) Merge touches all files with explicit mergeinfo even if content of
these files isn't touched by merged revisions. This can result in
inability to commit changes after merge.
Let's suppose that we have project with following structure:
[[
$
-trunk
--core
---corefile.txt <with some explicit mergeinfo>
--ui
---uifile.txt
]]
When user merges any change from a branch to the trunk, mergenfo for
$/trunk/core/corefile.txt will be changed (even if corefile.txt isn't
somehow touched by this change). And if user doesn't have write access
to the core folder then he will not be able to commit this change.
2) Mergeinfo produced during WC-to-WC copy differs from equivalent
REPO-to-REPO copy. If you copy file in working copy and there is no
mergeinfo in the working copy then the new file will get an empty
mergeinfo record. Similar REPO-to-REPO copy operation doesn't produce
empty mergeinfo record.
This problem was already discussed here:
http://svn.haxx.se/users/archive-2008-08/0471.shtml
3) Unnecessary mergeinfo records are produced on copy operations. If
user plainly renames file1.txt to file2.txt in the same folder then
file2.txt gets explicit merge even if file1.txt didn't have one. In
agile environments file renaming is performed very often and this
result in whole working copy filled by unnecessary mergeinfo records.
This slows down merge operation dramatically.
I would like to help fixing these problems. Please let me know if I
understand them correctly. Any suggestions regarding fixing these
problems would be very helpful.
--
With best regards,
Danil Shopyrin
VisualSVN Team
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> On Wed, Sep 3, 2008 at 2:22 PM, Danil Shopyrin <da...@visualsvn.com> wrote:
>>> However, Danil (or anyone else), if you have any ideas for how to fix
>>> this in the current 1.5 working copy or client code, please say them.
>>
>> Currently I'm working on set of patches for 1.5.x. I'm not very
>> familiar with internal Subversion code base :) That's why it's not
>> very fast process.
>
> Great. It might be worthwhile to present your ideas and design before
> investing too much work though. And of course all patches must be
> against trunk and there is no guarantee they will be backported for
> 1.5.x.
+1 We're happy to answer questions...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Sep 3, 2008 at 2:22 PM, Danil Shopyrin <da...@visualsvn.com> wrote:
>> However, Danil (or anyone else), if you have any ideas for how to fix
>> this in the current 1.5 working copy or client code, please say them.
>
> Currently I'm working on set of patches for 1.5.x. I'm not very
> familiar with internal Subversion code base :) That's why it's not
> very fast process.
Great. It might be worthwhile to present your ideas and design before
investing too much work though. And of course all patches must be
against trunk and there is no guarantee they will be backported for
1.5.x.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Danil Shopyrin <da...@visualsvn.com>.
> However, Danil (or anyone else), if you have any ideas for how to fix
> this in the current 1.5 working copy or client code, please say them.
Currently I'm working on set of patches for 1.5.x. I'm not very
familiar with internal Subversion code base :) That's why it's not
very fast process.
--
Danil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> Given that you make a product that profits from SVN, then I look
> forward to seeing you more active in the mail list and to receiving
> your patches to help us make it more usable. We are always looking
> for new contributors and it would be great to have you on board.
Well, to be fair, Danil has been more and more active lately -- the
bottleneck has more been our bandwidth to review patches!
> I think this problem is going to be tough for you to solve. I do not
> know if the client has a way of checking whether it can write to a
> patch in the repos, short of actually trying to do it. You could
> argue that we ought to not allow a user to add/delete and edit files
> in this folder either. And the fact that we do is also a bug. So I
> am guessing we will need new API to ask the server this information
> and then put it in the appropriate places. Of course if each time we
> update mergeinfo we have to make a server call to see if the client
> can write to that location, then that is not going to help performance
> either. Anyway, feel free to start a new thread to discuss your
> proposals for solving this problem.
I think the real solution to this has to come with the new WC, which
will be able to do real property inheritance -- that is, if the
properties explicitly attached to path CHILD don't change, then even if
CHILD is authz-protected, we can still affect its properties by changing
the properties of one of its parents.
However, Danil (or anyone else), if you have any ideas for how to fix
this in the current 1.5 working copy or client code, please say them.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Sep 3, 2008 at 5:08 AM, Danil Shopyrin <da...@visualsvn.com> wrote:
>> How could merge tracking be merge tracking if it does not do this? It
>> has to scan the working copy to find out if you have any subtree
>> mergeinfo.
>
> I don't agree. The authz-blocked path isn't somehow touched in the
> merging branch and it's surprising behavior when the user-visible
> properties of the file are changed. And it's unacceptable that commit
> is blocked because of this.
As I said to Karl, I was not responding to this part of the thread (I
forgot about it). I was talking about the performance hit of crawling
the WC, and just saying there is no way to avoid that.
>> I do not think it makes sense to try and change this. If we really
>> implement a new WC, this checking will become trivial as it will no
>> longer be crawling the WC to find this information. That seems like a
>> better solution given that the code is working as intended.
>
> From my point of view, the whole Subversion usability is seriously
> damaged since merge tracking was released in 1.5. I work with
> Subversion for several years and I was really disappointed by released
> behavior (and most of my friends too). Looks like a big broken window.
>
> That's why I think it's a good job to make merge tracking better in 1.5.x.
>
> --
> With best regards,
> Danil Shopyrin
> VisualSVN Team
Given that you make a product that profits from SVN, then I look
forward to seeing you more active in the mail list and to receiving
your patches to help us make it more usable. We are always looking
for new contributors and it would be great to have you on board.
I think this problem is going to be tough for you to solve. I do not
know if the client has a way of checking whether it can write to a
patch in the repos, short of actually trying to do it. You could
argue that we ought to not allow a user to add/delete and edit files
in this folder either. And the fact that we do is also a bug. So I
am guessing we will need new API to ask the server this information
and then put it in the appropriate places. Of course if each time we
update mergeinfo we have to make a server call to see if the client
can write to that location, then that is not going to help performance
either. Anyway, feel free to start a new thread to discuss your
proposals for solving this problem.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Danil Shopyrin <da...@visualsvn.com>.
> How could merge tracking be merge tracking if it does not do this? It
> has to scan the working copy to find out if you have any subtree
> mergeinfo.
I don't agree. The authz-blocked path isn't somehow touched in the
merging branch and it's surprising behavior when the user-visible
properties of the file are changed. And it's unacceptable that commit
is blocked because of this.
As stated in $/www/merge-tracking/summit.html:
[[
...Users are often very average developers/maintenance programmers.
]]
(I agree with that statement). The discussed behavior isn't a critical
problem for an experienced developer but it can be critical for a
junior. And merge tracking supposed to simplify things for juniors.
> I do not think it makes sense to try and change this. If we really
> implement a new WC, this checking will become trivial as it will no
> longer be crawling the WC to find this information. That seems like a
> better solution given that the code is working as intended.
Re: Useless explicit mergeinfo records
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> All that said, I thought your reponse was saying crawling the WC is a
> bug and I was responding to that specifically.
The only things that are ever bugs are user-visible behaviors.
Everything else is an implementation choice :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 2, 2008 at 1:57 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "Mark Phippard" <ma...@gmail.com> writes:
>>>> Not only that, but it is horribly slow due to the wc. 20-30 minutes
>>>> to do a merge operation really messed with our plans.
>>>
>>> I agree, and it seems like a pretty basic bug. Can you file an issue
>>> about it, linking to this thread (and the one you mention above)?
>>
>> How could merge tracking be merge tracking if it does not do this? It
>> has to scan the working copy to find out if you have any subtree
>> mergeinfo.
>>
>> I do not think it makes sense to try and change this. If we really
>> implement a new WC, this checking will become trivial as it will no
>> longer be crawling the WC to find this information. That seems like a
>> better solution given that the code is working as intended.
>
> We have a real problem: metadata *about* files is being treated (for
> authz purposes) as data *in* files, simply because we implemented the
> mergeinfo as a property.
>
> Thus a merge which does not actually change authz-protected files cannot
> be committed, because we have no way of committing statements about
> those files without committing changes to the files themselves.
>
> The new WC will make things easier; it may open the door to totally
> changing how we record mergeinfo (since, among other things, it will
> make property inheritance much easier).
>
> Unrelatedly, the slowness is still a bug, of course.
So I think the answer is to look for a way to implement this feature
that does not use properties. In this specific case, the user will
have to omit the item from the commit.
All that said, I thought your reponse was saying crawling the WC is a
bug and I was responding to that specifically.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
>>> Not only that, but it is horribly slow due to the wc. 20-30 minutes
>>> to do a merge operation really messed with our plans.
>>
>> I agree, and it seems like a pretty basic bug. Can you file an issue
>> about it, linking to this thread (and the one you mention above)?
>
> How could merge tracking be merge tracking if it does not do this? It
> has to scan the working copy to find out if you have any subtree
> mergeinfo.
>
> I do not think it makes sense to try and change this. If we really
> implement a new WC, this checking will become trivial as it will no
> longer be crawling the WC to find this information. That seems like a
> better solution given that the code is working as intended.
We have a real problem: metadata *about* files is being treated (for
authz purposes) as data *in* files, simply because we implemented the
mergeinfo as a property.
Thus a merge which does not actually change authz-protected files cannot
be committed, because we have no way of committing statements about
those files without committing changes to the files themselves.
The new WC will make things easier; it may open the door to totally
changing how we record mergeinfo (since, among other things, it will
make property inheritance much easier).
Unrelatedly, the slowness is still a bug, of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 2, 2008 at 10:51 AM, Karl Fogel <kf...@red-bean.com> wrote:
> "Peter Wemm" <pe...@wemm.org> writes:
>> On Fri, Aug 29, 2008 at 2:22 AM, Vincent Lefevre <vi...@vinc17.org> wrote:
>>> On 2008-08-27 17:00:26 +0400, Danil Shopyrin wrote:
>>>> 1) Merge touches all files with explicit mergeinfo even if content of
>>>> these files isn't touched by merged revisions. This can result in
>>>> inability to commit changes after merge.
>>>
>>> Yes, I noted this problem in the users ML:
>>>
>>> "svn merge" scans the whole wc and deletes svn:mergeinfo properties
>>>
>>> This is really annoying. Even if there are technical reasons, this
>>> should be regarded as a bug IMHO.
>>
>> Not only that, but it is horribly slow due to the wc. 20-30 minutes
>> to do a merge operation really messed with our plans.
>
> I agree, and it seems like a pretty basic bug. Can you file an issue
> about it, linking to this thread (and the one you mention above)?
How could merge tracking be merge tracking if it does not do this? It
has to scan the working copy to find out if you have any subtree
mergeinfo.
I do not think it makes sense to try and change this. If we really
implement a new WC, this checking will become trivial as it will no
longer be crawling the WC to find this information. That seems like a
better solution given that the code is working as intended.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Karl Fogel <kf...@red-bean.com>.
"Peter Wemm" <pe...@wemm.org> writes:
> On Fri, Aug 29, 2008 at 2:22 AM, Vincent Lefevre <vi...@vinc17.org> wrote:
>> On 2008-08-27 17:00:26 +0400, Danil Shopyrin wrote:
>>> 1) Merge touches all files with explicit mergeinfo even if content of
>>> these files isn't touched by merged revisions. This can result in
>>> inability to commit changes after merge.
>>
>> Yes, I noted this problem in the users ML:
>>
>> "svn merge" scans the whole wc and deletes svn:mergeinfo properties
>>
>> This is really annoying. Even if there are technical reasons, this
>> should be regarded as a bug IMHO.
>
> Not only that, but it is horribly slow due to the wc. 20-30 minutes
> to do a merge operation really messed with our plans.
I agree, and it seems like a pretty basic bug. Can you file an issue
about it, linking to this thread (and the one you mention above)?
Danil, a workaround for this problem...
> When user merges any change from a branch to the trunk, mergenfo for
> $/trunk/core/corefile.txt will be changed (even if corefile.txt isn't
> somehow touched by this change). And if user doesn't have write access
> to the core folder then he will not be able to commit this change.
... is to simply exclude the authz-blocked path from the commit, by
naming commit targets explicitly. That's cumbersome, but it can be
done until this situation is fixed.
By the way, I also looked in the issue tracker for an issue about this,
and didn't see any. FWIW, I specifically checked these:
http://subversion.tigris.org/issues/show_bug.cgi?id=3056
http://subversion.tigris.org/issues/show_bug.cgi?id=2838
http://subversion.tigris.org/issues/show_bug.cgi?id=2898
http://subversion.tigris.org/issues/show_bug.cgi?id=2970
http://subversion.tigris.org/issues/show_bug.cgi?id=2833
http://subversion.tigris.org/issues/show_bug.cgi?id=3067
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Peter Wemm <pe...@wemm.org>.
On Fri, Aug 29, 2008 at 2:22 AM, Vincent Lefevre <vi...@vinc17.org> wrote:
> On 2008-08-27 17:00:26 +0400, Danil Shopyrin wrote:
>> 1) Merge touches all files with explicit mergeinfo even if content of
>> these files isn't touched by merged revisions. This can result in
>> inability to commit changes after merge.
>
> Yes, I noted this problem in the users ML:
>
> "svn merge" scans the whole wc and deletes svn:mergeinfo properties
>
> This is really annoying. Even if there are technical reasons, this
> should be regarded as a bug IMHO.
Not only that, but it is horribly slow due to the wc. 20-30 minutes
to do a merge operation really messed with our plans.
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2008-08-27 17:00:26 +0400, Danil Shopyrin wrote:
> 1) Merge touches all files with explicit mergeinfo even if content of
> these files isn't touched by merged revisions. This can result in
> inability to commit changes after merge.
Yes, I noted this problem in the users ML:
"svn merge" scans the whole wc and deletes svn:mergeinfo properties
This is really annoying. Even if there are technical reasons, this
should be regarded as a bug IMHO.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Danil Shopyrin <da...@visualsvn.com>.
> We toyed with this, but the problem (or one of the problems) we ran into was
> what happened if you performed a copy (perhaps to make a local branch), then
> tried to merge into it. The merge needs that mergeinfo as much as commit
> might. And maybe the answer there that 'merge' also grows the ability to
> detect stale-and-in-need-of-network-refreshing mergeinfo on working copy
> members, and does said refreshing before performing its primary task. I dunno.
We have some other ideas how to fix this. I've just posted the
corresponding patch at
http://svn.haxx.se/dev/archive-2008-09/0331.shtml
Looking forward for your comments.
--
Danil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by Ivan Zhakov <ch...@gmail.com>.
On Wed, Aug 27, 2008 at 6:29 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Danil Shopyrin wrote:
>>>> 2) Mergeinfo produced during WC-to-WC copy differs from equivalent
>>>> REPO-to-REPO copy. If you copy file in working copy and there is no
>>>> mergeinfo in the working copy then the new file will get an empty
>>>> mergeinfo record. Similar REPO-to-REPO copy operation doesn't produce
>>>> empty mergeinfo record.
>>>>
>>>> This problem was already discussed here:
>>>> http://svn.haxx.se/users/archive-2008-08/0471.shtml
>>> That's correct. A WC-to-WC copy isn't allowed to speak to the repository,
>>> so it doesn't have the opportunity to verify that "no mergeinfo" is the
>>> correct result. To be safe, it sets empty mergeinfo (to block any
>>> inheritence it couldn't have foreseen due to lack of repository access). As
>>> you note below, though, there are some cases when we can be smarter about this.
>>
>> Can appropriate checks be done at commit stage? The logic can be as
>> follows: if we have "added and copied" paths then we should compute
>> appropriate mergeinfo for them. As I understand, there is no problems
>> with connection to the repository at commit stage.
>
> We toyed with this, but the problem (or one of the problems) we ran into was
> what happened if you performed a copy (perhaps to make a local branch), then
> tried to merge into it. The merge needs that mergeinfo as much as commit
> might. And maybe the answer there that 'merge' also grows the ability to
> detect stale-and-in-need-of-network-refreshing mergeinfo on working copy
> members, and does said refreshing before performing its primary task. I dunno.
Another option is create empty svn:mergeinfo on copy when we cannot is
it inherited or not and resolve svn:mergeinfo on the commit. Only
problem is commit could be slightly different from what user see in
svn status.
But we could consider svn:mergeinfo as special property and maybe
never show it in svn status?
--
Ivan Zhakov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by "C. Michael Pilato" <cm...@collab.net>.
Danil Shopyrin wrote:
>>> 2) Mergeinfo produced during WC-to-WC copy differs from equivalent
>>> REPO-to-REPO copy. If you copy file in working copy and there is no
>>> mergeinfo in the working copy then the new file will get an empty
>>> mergeinfo record. Similar REPO-to-REPO copy operation doesn't produce
>>> empty mergeinfo record.
>>>
>>> This problem was already discussed here:
>>> http://svn.haxx.se/users/archive-2008-08/0471.shtml
>> That's correct. A WC-to-WC copy isn't allowed to speak to the repository,
>> so it doesn't have the opportunity to verify that "no mergeinfo" is the
>> correct result. To be safe, it sets empty mergeinfo (to block any
>> inheritence it couldn't have foreseen due to lack of repository access). As
>> you note below, though, there are some cases when we can be smarter about this.
>
> Can appropriate checks be done at commit stage? The logic can be as
> follows: if we have "added and copied" paths then we should compute
> appropriate mergeinfo for them. As I understand, there is no problems
> with connection to the repository at commit stage.
We toyed with this, but the problem (or one of the problems) we ran into was
what happened if you performed a copy (perhaps to make a local branch), then
tried to merge into it. The merge needs that mergeinfo as much as commit
might. And maybe the answer there that 'merge' also grows the ability to
detect stale-and-in-need-of-network-refreshing mergeinfo on working copy
members, and does said refreshing before performing its primary task. I dunno.
> I can provide a 'very dirty prototype patch' if this solution is acceptable.
That's fine. Just understand that while very dirty prototype patches are
interesting, but nice clean ready-for-commit patches get more attention. :-)
>>> 3) Unnecessary mergeinfo records are produced on copy operations. If
>>> user plainly renames file1.txt to file2.txt in the same folder then
>>> file2.txt gets explicit merge even if file1.txt didn't have one. In
>>> agile environments file renaming is performed very often and this
>>> result in whole working copy filled by unnecessary mergeinfo records.
>>> This slows down merge operation dramatically.
>> We agree. I thought there was an issue for this already, but I can't find
>> it. In general, the behavior should be: Figure out what the mergeinfo for
>> the target would be, and if it's no different than the mergeinfo for the
>> source location, don't set/change it.
>
> I also found that these unnecessary mergeinfo records also break
> 'svn merge --reintegrate' command. Empty mergeinfo records break
> --reintegrate option too. This is also described by Mark Phippard at
> http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
Yep. This is actually something I was hoping to work on over the past few
weeks, but other responsibilities have prevented it. If you'd like to take
a crack at it, that's be great. I think you'll find that you need to focus
only on the logic in libsvn_client/copy.c.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Useless explicit mergeinfo records
Posted by Danil Shopyrin <da...@visualsvn.com>.
>> 2) Mergeinfo produced during WC-to-WC copy differs from equivalent
>> REPO-to-REPO copy. If you copy file in working copy and there is no
>> mergeinfo in the working copy then the new file will get an empty
>> mergeinfo record. Similar REPO-to-REPO copy operation doesn't produce
>> empty mergeinfo record.
>>
>> This problem was already discussed here:
>> http://svn.haxx.se/users/archive-2008-08/0471.shtml
>
> That's correct. A WC-to-WC copy isn't allowed to speak to the repository,
> so it doesn't have the opportunity to verify that "no mergeinfo" is the
> correct result. To be safe, it sets empty mergeinfo (to block any
> inheritence it couldn't have foreseen due to lack of repository access). As
> you note below, though, there are some cases when we can be smarter about this.
Can appropriate checks be done at commit stage? The logic can be as
follows: if we have "added and copied" paths then we should compute
appropriate mergeinfo for them. As I understand, there is no problems
with connection to the repository at commit stage.
I can provide a 'very dirty prototype patch' if this solution is acceptable.
>> 3) Unnecessary mergeinfo records are produced on copy operations. If
>> user plainly renames file1.txt to file2.txt in the same folder then
>> file2.txt gets explicit merge even if file1.txt didn't have one. In
>> agile environments file renaming is performed very often and this
>> result in whole working copy filled by unnecessary mergeinfo records.
>> This slows down merge operation dramatically.
>
> We agree. I thought there was an issue for this already, but I can't find
> it. In general, the behavior should be: Figure out what the mergeinfo for
> the target would be, and if it's no different than the mergeinfo for the
> source location, don't set/change it.
I also found that these unnecessary mergeinfo records also break
'svn merge --reintegrate' command. Empty mergeinfo records break
--reintegrate option too. This is also described by Mark Phippard at
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Useless explicit mergeinfo records
Posted by "C. Michael Pilato" <cm...@collab.net>.
Danil Shopyrin wrote:
> 2) Mergeinfo produced during WC-to-WC copy differs from equivalent
> REPO-to-REPO copy. If you copy file in working copy and there is no
> mergeinfo in the working copy then the new file will get an empty
> mergeinfo record. Similar REPO-to-REPO copy operation doesn't produce
> empty mergeinfo record.
>
> This problem was already discussed here:
> http://svn.haxx.se/users/archive-2008-08/0471.shtml
That's correct. A WC-to-WC copy isn't allowed to speak to the repository,
so it doesn't have the opportunity to verify that "no mergeinfo" is the
correct result. To be safe, it sets empty mergeinfo (to block any
inheritence it couldn't have foreseen due to lack of repository access). As
you note below, though, there are some cases when we can be smarter about this.
> 3) Unnecessary mergeinfo records are produced on copy operations. If
> user plainly renames file1.txt to file2.txt in the same folder then
> file2.txt gets explicit merge even if file1.txt didn't have one. In
> agile environments file renaming is performed very often and this
> result in whole working copy filled by unnecessary mergeinfo records.
> This slows down merge operation dramatically.
We agree. I thought there was an issue for this already, but I can't find
it. In general, the behavior should be: Figure out what the mergeinfo for
the target would be, and if it's no different than the mergeinfo for the
source location, don't set/change it.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand