Re: Subversion checked-out files not indexed in Windows search
Ivan Zhakov visualsvn.com> writes: > > On 10 March 2014 18:25, Gareth McCaughan > lightblueoptics.com> wrote: > > It appears that files checked out using Subversion (1.7 onwards) > > are marked as not indexable by Windows search. The way in which > > this happens appears to be as follows: Wouldn't it be the easiest way to copy the temporary file (in such a case it gets the default attributes and ACLs of the destination folder) and after that erase the original temporary file?
Re: thrash emails from admin -- was: Fwd: Notice about your recent message to us...@subversion.tigris.org
Quoting "marc gonzalez-carnicer" : it's been already several weeks since the migration to apache, and i am getting these annoying emails all the time. can't the mailing list be tuned for avoiding these messages? am i the only one to get them? No, I'm also getting them as well. What's annoying is I can't find the un-subscribe information anywhere for the old list and also ad...@subversion.tigris.org is a non-deliverable address. I suspect my unsubscribe to ad...@subversion.tigris.org request just got bounced to the us...@subversion.tigris.org - sorry if it did. Anyone know the unsubscribe information for the old list? Pete Hatton - E-mail: p...@monolight.org Webpage: http://www.monolight.org -
Re: thrash emails from admin -- was: Fwd: Notice about your recentmessage to us...@subversion.tigris.org
Quoting "Stein Somers" : Much easier is to unsubscribe from this spambot by sending an empty e-mail to users-unsubscr...@subversion.tigris.org Thanks - that was what I was looking for. Seems to have worked as well. Pete Hatton - E-mail: p...@monolight.org Webpage: http://www.monolight.org -
1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
Hi,
Subversion 1.8.11 behaves differently than 1.7.17 and 1.6.11, in that
it sets empty svn:mergeinfo properties for files within a
tree-conflicted directory during a merge. The effect is this:
Layout:
/trunk
/branches/branch
Add empty dir/file.txt to trunk and independently to branch.
Merge trunk to branch; the resulting merge generates:
% svn propget -v svn:mergeinfo -R
Properties on '.':
svn:mergeinfo
/trunk:2-4
Properties on 'dir/file.txt':
svn:mergeinfo
%
Expected result is that no svn:mergeinfo property would appear on
dir/file.txt. Is this a bug? A known bug?
Thanks,
Pete
Script to reproduce (run as "script.sh /path/to/svn"):
#!/bin/bash
#
# Reproduce an issue in Subversion 1.8.11 where files in a tree
# conflict can have svn:mergeinfo properties added to them during a
# merge.
set -e
SERVER_DIR=server
CLIENT_DIR=client
if [ $# != 1 ]; then
echo "usage: $0 "
exit
fi
SVN=$1
SVNADMIN="$(dirname $SVN)/svnadmin"
SERVER_URL="file:///$PWD/$SERVER_DIR"
createAndCommitSubdirWithFile ()
{
mkdir dir
touch dir/file.txt
$SVN add dir
$SVN commit -m "$1"
$SVN update # Update . to committed rev
}
# Create the repo and enter it.
$SVNADMIN create $SERVER_DIR
$SVN checkout $SERVER_URL $CLIENT_DIR
cd $CLIENT_DIR
# Create the trunk/branches structure
mkdir trunk
mkdir branches
$SVN add trunk branches
$SVN commit -m 'Create initial structure'
# Make a branch from the trunk.
$SVN copy ^/trunk ^/branches/branch -m 'Create branch from trunk'
# Commit a subdir with a file in it in the trunk and commit it.
$SVN switch --ignore-ancestry ^/trunk
createAndCommitSubdirWithFile 'Committed on trunk'
# Commit a subdir with a file in it in the branch and commit it.
$SVN switch ^/branches/branch
createAndCommitSubdirWithFile 'Committed on branch'
# Merge the trunk and display any svn:mergeinfo properties.
# (Remove --non-interactive if testing svn prior to 1.7)
$SVN merge --non-interactive ^/trunk || true
$SVN propget svn:mergeinfo -R . >actual.out
echo '. - /trunk:2-4' >expected.out
$SVN --version | head -1
if diff -q actual.out expected.out; then
echo Success
else
echo 'Test failed!'
echo 'Expected output:'
cat expected.out
echo 'Actual output:'
cat actual.out
exit 1
fi
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
Thank you for your reply.
> the mergeinfo tells that it didn't merge to that node.
Once I've resolved the tree conflict, is there a sense in which it
didn't merge everything in /trunk into /branches/branch? Marking the
tree conflict resolved doesn't remove the svn:mergeinfo property from
dir/file.txt, but from my perspective, I've told Subversion how to
resolve the merge and therefore want it to consider the two branches
fully merged going forward.
If the behavior is intentional, what is the recommended way to tell
Subversion that I consider the two paths fully merged? And is this
difference meant to be introduced in 1.8 vs. 1.7? From what I read it
looked like merge semantics weren't intended to change, just some of
the client-side bookkeeping.
Thank you for your time,
--Pete
On Wed, Mar 11, 2015 at 4:25 PM, Bert Huijben wrote:
> I don’t know whether it is a bug or a feature. Storing this value will make
> a future merge handle the partial merge that was skipped at first: the
> mergeinfo tells that it didn't merge to that node.
>
> There are two ways to remember that: record ‘non inheritable’ info on the
> direct parent, and then again on all children that are merged… The untouched
> node is then unaffected, but future merges will be slower as more nodes have
> specific merge-info. Storing it just on the node that is not merged as you
> see here is the other option, which will keep your further merges faster.
>
> In 1.6 we could in general not change the node affected by a tree conflict,
> so we always had to choose the slow option. With the central metadata
> storage we can do things more efficient… and this allowed fixing a lot of
> known issues of previous versions.
>
> Bert
> Sent from Windows Mail
>
> From: Pete Harlan
> Sent: Wednesday, March 11, 2015 11:16 PM
> To: 'subversion'
>
> Hi,
>
> Subversion 1.8.11 behaves differently than 1.7.17 and 1.6.11, in that
> it sets empty svn:mergeinfo properties for files within a
> tree-conflicted directory during a merge. The effect is this:
>
> Layout:
>
> /trunk
> /branches/branch
>
> Add empty dir/file.txt to trunk and independently to branch.
> Merge trunk to branch; the resulting merge generates:
>
> % svn propget -v svn:mergeinfo -R
> Properties on '.':
> svn:mergeinfo
> /trunk:2-4
> Properties on 'dir/file.txt':
> svn:mergeinfo
>
> %
>
> Expected result is that no svn:mergeinfo property would appear on
> dir/file.txt. Is this a bug? A known bug?
>
> Thanks,
> Pete
>
> Script to reproduce (run as "script.sh /path/to/svn"):
>
> #!/bin/bash
> #
> # Reproduce an issue in Subversion 1.8.11 where files in a tree
> # conflict can have svn:mergeinfo properties added to them during a
> # merge.
> set -e
>
> SERVER_DIR=server
> CLIENT_DIR=client
>
> if [ $# != 1 ]; then
> echo "usage: $0 "
> exit
> fi
>
> SVN=$1
> SVNADMIN="$(dirname $SVN)/svnadmin"
>
> SERVER_URL="file:///$PWD/$SERVER_DIR"
>
> createAndCommitSubdirWithFile ()
> {
> mkdir dir
> touch dir/file.txt
> $SVN add dir
> $SVN commit -m "$1"
> $SVN update # Update . to committed rev
> }
>
> # Create the repo and enter it.
> $SVNADMIN create $SERVER_DIR
> $SVN checkout $SERVER_URL $CLIENT_DIR
> cd $CLIENT_DIR
>
> # Create the trunk/branches structure
> mkdir trunk
> mkdir branches
> $SVN add trunk branches
> $SVN commit -m 'Create initial structure'
>
> # Make a branch from the trunk.
> $SVN copy ^/trunk ^/branches/branch -m 'Create branch from trunk'
>
> # Commit a subdir with a file in it in the trunk and commit it.
> $SVN switch --ignore-ancestry ^/trunk
> createAndCommitSubdirWithFile 'Committed on trunk'
>
> # Commit a subdir with a file in it in the branch and commit it.
> $SVN switch ^/branches/branch
> createAndCommitSubdirWithFile 'Committed on branch'
>
> # Merge the trunk and display any svn:mergeinfo properties.
> # (Remove --non-interactive if testing svn prior to 1.7)
> $SVN merge --non-interactive ^/trunk || true
> $SVN propget svn:mergeinfo -R . >actual.out
>
> echo '. - /trunk:2-4' >expected.out
>
> $SVN --version | head -1
>
> if diff -q actual.out expected.out; then
> echo Success
> else
> echo 'Test failed!'
> echo 'Expected output:'
> cat expected.out
> echo 'Actual output:'
> cat actual.out
> exit 1
> fi
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
I verified that this test also fails the same way on the latest
subversion trunk (1.10.0-dev).
Pass: 1.6.11
Pass: 1.7.17
Fail: 1.8.11
Fail: 1.10.0-dev
Is there a reason not to open a bug report?
Thanks,
--Pete
On Wed, Mar 11, 2015 at 4:54 PM, Pete Harlan wrote:
> Thank you for your reply.
>
>> the mergeinfo tells that it didn't merge to that node.
>
> Once I've resolved the tree conflict, is there a sense in which it
> didn't merge everything in /trunk into /branches/branch? Marking the
> tree conflict resolved doesn't remove the svn:mergeinfo property from
> dir/file.txt, but from my perspective, I've told Subversion how to
> resolve the merge and therefore want it to consider the two branches
> fully merged going forward.
>
> If the behavior is intentional, what is the recommended way to tell
> Subversion that I consider the two paths fully merged? And is this
> difference meant to be introduced in 1.8 vs. 1.7? From what I read it
> looked like merge semantics weren't intended to change, just some of
> the client-side bookkeeping.
>
> Thank you for your time,
>
> --Pete
>
> On Wed, Mar 11, 2015 at 4:25 PM, Bert Huijben wrote:
>> I don’t know whether it is a bug or a feature. Storing this value will make
>> a future merge handle the partial merge that was skipped at first: the
>> mergeinfo tells that it didn't merge to that node.
>>
>> There are two ways to remember that: record ‘non inheritable’ info on the
>> direct parent, and then again on all children that are merged… The untouched
>> node is then unaffected, but future merges will be slower as more nodes have
>> specific merge-info. Storing it just on the node that is not merged as you
>> see here is the other option, which will keep your further merges faster.
>>
>> In 1.6 we could in general not change the node affected by a tree conflict,
>> so we always had to choose the slow option. With the central metadata
>> storage we can do things more efficient… and this allowed fixing a lot of
>> known issues of previous versions.
>>
>> Bert
>> Sent from Windows Mail
>>
>> From: Pete Harlan
>> Sent: Wednesday, March 11, 2015 11:16 PM
>> To: 'subversion'
>>
>> Hi,
>>
>> Subversion 1.8.11 behaves differently than 1.7.17 and 1.6.11, in that
>> it sets empty svn:mergeinfo properties for files within a
>> tree-conflicted directory during a merge. The effect is this:
>>
>> Layout:
>>
>> /trunk
>> /branches/branch
>>
>> Add empty dir/file.txt to trunk and independently to branch.
>> Merge trunk to branch; the resulting merge generates:
>>
>> % svn propget -v svn:mergeinfo -R
>> Properties on '.':
>> svn:mergeinfo
>> /trunk:2-4
>> Properties on 'dir/file.txt':
>> svn:mergeinfo
>>
>> %
>>
>> Expected result is that no svn:mergeinfo property would appear on
>> dir/file.txt. Is this a bug? A known bug?
>>
>> Thanks,
>> Pete
>>
>> Script to reproduce (run as "script.sh /path/to/svn"):
>>
>> #!/bin/bash
>> #
>> # Reproduce an issue in Subversion 1.8.11 where files in a tree
>> # conflict can have svn:mergeinfo properties added to them during a
>> # merge.
>> set -e
>>
>> SERVER_DIR=server
>> CLIENT_DIR=client
>>
>> if [ $# != 1 ]; then
>> echo "usage: $0 "
>> exit
>> fi
>>
>> SVN=$1
>> SVNADMIN="$(dirname $SVN)/svnadmin"
>>
>> SERVER_URL="file:///$PWD/$SERVER_DIR"
>>
>> createAndCommitSubdirWithFile ()
>> {
>> mkdir dir
>> touch dir/file.txt
>> $SVN add dir
>> $SVN commit -m "$1"
>> $SVN update # Update . to committed rev
>> }
>>
>> # Create the repo and enter it.
>> $SVNADMIN create $SERVER_DIR
>> $SVN checkout $SERVER_URL $CLIENT_DIR
>> cd $CLIENT_DIR
>>
>> # Create the trunk/branches structure
>> mkdir trunk
>> mkdir branches
>> $SVN add trunk branches
>> $SVN commit -m 'Create initial structure'
>>
>> # Make a branch from the trunk.
>> $SVN copy ^/trunk ^/branches/branch -m 'Create branch from trunk'
>>
>> # Commit a subdir with a file in it in the trunk and commit it.
>> $SVN switch --ignore-ancestry ^/trunk
>> createAndCommitSubdirWithFile 'Committed on trunk'
>>
>> # Commit a subdir with a file in it in the branch and commit it.
>> $SVN switch ^/branches/branch
>> createAndCommitSubdirWithFile 'Committed on branch'
>>
>> # Merge the trunk and display any svn:mergeinfo properties.
>> # (Remove --non-interactive if testing svn prior to 1.7)
>> $SVN merge --non-interactive ^/trunk || true
>> $SVN propget svn:mergeinfo -R . >actual.out
>>
>> echo '. - /trunk:2-4' >expected.out
>>
>> $SVN --version | head -1
>>
>> if diff -q actual.out expected.out; then
>> echo Success
>> else
>> echo 'Test failed!'
>> echo 'Expected output:'
>> cat expected.out
>> echo 'Actual output:'
>> cat actual.out
>> exit 1
>> fi
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
Hi, I narrowed down the change to this commit, in version 1.8.0-dev: r1441043 | rhuijben | 2013-01-31 08:20:25 -0800 (Thu, 31 Jan 2013) | 30 lines Following up on r1440966, also handle file obstruction handling in the merge from the file_openened function. * subversion/libsvn_client/merge.c (merge_file_baton_t): Add fields to store conflicts and skips. (mark_dir_edited): Add comment. (mark_file_edited): Handle skips and tree conflicts on files. (merge_file_opened): Handle obstruction handling for changes, adds, deletes and persist the result in the baton. Or notify if we know the result for delete/add. (merge_file_changed, merge_file_added, merge_file_deleted): Replace obstruction check with simple baton readout. (merge_dir_opened): Tweak comment. * subversion/tests/cmdline/merge_authz_tests.py (mergeinfo_and_skipped_paths): Expect detailed skip. * subversion/tests/cmdline/merge_tests.py (merge_to_sparse_directories): Expect detailed skip. * subversion/tests/cmdline/merge_tree_conflict_tests.py (tree_conflicts_merge_edit_onto_missing): Expect detailed skip. * subversion/tests/cmdline/tree_conflict_tests.py (at_directory_external): Remove Wimp marker (added in r1440966) I don't know Subversion internals so I haven't dug in further than this. Is there a way that I should be resolving the tree conflict that would tell Subversion that I don't want the subdirectory to have a detached svn:mergeinfo? I'm using "svn resolve --accept=working " but that leaves the property in place on the file within path. Lack of understanding this issue is preventing us from moving past 1.7; any help would be most appreciated. Thank you, --Pete On Thu, Mar 12, 2015 at 3:50 PM, Pete Harlan wrote: > I verified that this test also fails the same way on the latest > subversion trunk (1.10.0-dev). > > Pass: 1.6.11 > Pass: 1.7.17 > > Fail: 1.8.11 > Fail: 1.10.0-dev > > Is there a reason not to open a bug report? > > Thanks, > > --Pete > > On Wed, Mar 11, 2015 at 4:54 PM, Pete Harlan wrote: >> Thank you for your reply. >> >>> the mergeinfo tells that it didn't merge to that node. >> >> Once I've resolved the tree conflict, is there a sense in which it >> didn't merge everything in /trunk into /branches/branch? Marking the >> tree conflict resolved doesn't remove the svn:mergeinfo property from >> dir/file.txt, but from my perspective, I've told Subversion how to >> resolve the merge and therefore want it to consider the two branches >> fully merged going forward. >> >> If the behavior is intentional, what is the recommended way to tell >> Subversion that I consider the two paths fully merged? And is this >> difference meant to be introduced in 1.8 vs. 1.7? From what I read it >> looked like merge semantics weren't intended to change, just some of >> the client-side bookkeeping. >> >> Thank you for your time, >> >> --Pete >> >> On Wed, Mar 11, 2015 at 4:25 PM, Bert Huijben wrote: >>> I don’t know whether it is a bug or a feature. Storing this value will make >>> a future merge handle the partial merge that was skipped at first: the >>> mergeinfo tells that it didn't merge to that node. >>> >>> There are two ways to remember that: record ‘non inheritable’ info on the >>> direct parent, and then again on all children that are merged… The untouched >>> node is then unaffected, but future merges will be slower as more nodes have >>> specific merge-info. Storing it just on the node that is not merged as you >>> see here is the other option, which will keep your further merges faster. >>> >>> In 1.6 we could in general not change the node affected by a tree conflict, >>> so we always had to choose the slow option. With the central metadata >>> storage we can do things more efficient… and this allowed fixing a lot of >>> known issues of previous versions. >>> >>> Bert >>> Sent from Windows Mail >>> >>> From: Pete Harlan >>> Sent: Wednesday, March 11, 2015 11:16 PM >>> To: 'subversion' >>> >>> Hi, >>> >>> Subversion 1.8.11 behaves differently than 1.7.17 and 1.6.11, in that >>> it sets empty svn:mergeinfo properties for files within a >>> tree-conflicted directory during a merge. The effect is this: >>> >>> Layout: >>> >>> /trunk >>> /branches/branch >>> >>> Add empty dir/file.txt to trunk and independently to branch. >>> Merge trunk to
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
Thank you for your response! This may demonstrate my question more clearly: The script I posted creates an empty trunk and a branch from it, and then creates dir/file.txt in both trunk and branch separately, and then merges trunk to branch, resulting in this tree conflict: % svn st M . C dir > local dir obstruction, incoming dir add upon merge M dir/file.txt Summary of conflicts: Tree conflicts: 1 The path dir/file.txt gains an (empty) svn:mergeinfo property that remains after resolving and committing the merge: % svn propget svn:mergeinfo -R . - /trunk:2-4 dir/file.txt - % svn resolve --accept=working dir dir/file.txt Resolved conflicted state of 'dir' % svn commit -m 'Merge from trunk' Sending. Sendingdir/file.txt Committed revision 5. % svn propget svn:mergeinfo -R . - /trunk:2-4 dir/file.txt - Question #1: Once the user has resolved the conflict, why treat dir/file.txt differently than any other file involved in the merge from trunk? I have resolved the merge to my satsifaction, and do not wish to treat subpaths specially. Question #2: If Subversion were to set dir/file.txt's svn:mergeinfo property to "/trunk:2-4" after the resolution and prior to the commit, would this reflect what the user intends, and then cause it to be elided and disappear? Interestingly (perhaps?), if I modify dir/file.txt on trunk and merge that back into branch, the message from Subversion doesn't agree with what it writes into file.txt's svn:mergeinfo property: % svn merge ^/trunk --- Merging r5 through r6 into '.': Udir/file.txt --- Recording mergeinfo for merge of r2 through r6 into '.': U . --- Recording mergeinfo for merge of r2 through r6 into 'dir/file.txt': U dir/file.txt % svn propget -v svn:mergeinfo -R Properties on '.': svn:mergeinfo /trunk:2-6 Properties on 'dir/file.txt': svn:mergeinfo /trunk/dir/file.txt:3-6 The merge says it's recording r2 through r6 into dir/file.txt, but instead it records 3-6. (Trunk didn't change in revision 2, so the two ranges represent the same set of changes.) Question #3: If I remove the svn:mergeinfo property on dir/file.txt prior to committing the first merge, future merges appear to happen normally and all is happy. Is removing that property going to create a problem down the road? If the answer to #3 is "removing the property does not create a problem, since the user completely resolved all conflicts", then I would argue that it would be nice if this happened automatically (as in #2), restoring the pre-1.8 behavior. Or am I misunderstanding something about the svn:mergeinfo property or conflict resolution that would explain the need to track dir/file.txt specially on an ongoing basis? Thank you for your time. Pete On Fri, Mar 13, 2015 at 5:10 PM, Bert Huijben wrote: > > >> -Original Message- >> From: Pete Harlan [mailto:pchpubli...@gmail.com] >> Sent: vrijdag 13 maart 2015 23:18 >> To: Bert Huijben >> Cc: subversion >> Subject: Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in >> subdirs >> >> Hi, >> >> I narrowed down the change to this commit, in version 1.8.0-dev: >> >> >> r1441043 | rhuijben | 2013-01-31 08:20:25 -0800 (Thu, 31 Jan 2013) | >> 30 lines >> >> Following up on r1440966, also handle file obstruction handling in the merge >> from the file_openened function. >> >> * subversion/libsvn_client/merge.c >> (merge_file_baton_t): Add fields to store conflicts and skips. >> (mark_dir_edited): Add comment. >> (mark_file_edited): Handle skips and tree conflicts on files. >> >> (merge_file_opened): Handle obstruction handling for changes, adds, deletes >> and persist the result in the baton. Or notify if we know the result for >> delete/add. >> >> (merge_file_changed, >>merge_file_added, >>merge_file_deleted): Replace obstruction check with simple baton readout. >> >> (merge_dir_opened): Tweak comment. >> >> * subversion/tests/cmdline/merge_authz_tests.py >> (mergeinfo_and_skipped_paths): Expect detailed skip. >> >> * subversion/tests/cmdline/merge_tests.py >> (merge_to_sparse_directories): Expect detailed skip. >> >> * subversion/tests/cmdline/merge_tree_conflict_tests.py >> (tree_conflicts_merge_edit_onto_missing): Expect detailed skip. >> >> * subversion/tests/cmdline/tree_conflict_tests.py >> (at_directory_external): Remove Wimp marker (added in r1440966) >> >> I don't know Subversion internals so I haven't dug in further than >> this.
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Sat, Mar 14, 2015 at 7:45 AM, Bert Huijben wrote: > Looking further (after turning your test in a regression test), I think this > shows another problem. The conflict is on 'dir', not really on file. > > But (for legacy reasons) we somehow think that conflicting directory adds are > something that we can usually just ignore (because there is no real > difference between directories). So the merge of dir is somehow auto > resolved, but then still conflicts via file.txt. > > If file is not added because there is a conflict on 'dir' that mergeinfo > should really be on 'dir' instead of 'dir/file.txt'... > > Where also the tree conflict is stored. > > > As the merge determined that 'file.txt' in the working copy, and 'file.txt' > as merged are completely different nodes, it should have never changed the > unrelated 'file.txt'. > > I think this partially answers your question... and shows a real problem. > (This problem is fixed in r190) > > The problem is now how would we resolve this in the future: > > We still have a tree conflict. One directory with files obstructing another > directory with files... > Or as 'svn info' describes it: > [[ > Tree conflict: local dir obstruction, incoming dir add upon merge >Source left: (none) ^/trunk/dir@1 >Source right: (dir) ^/trunk/dir@4 > ]] > > I can see three ways to resolve from this situation: > * Accept whatever is currently here, as the merged situation. (accept > mine-full ?) > This should just record the merge as happened and then elide with the parent. > (I thinks this matches your expectation. But it isn't implemented yet) > > * Accept that what is merged in should be kept. (accept theirs-full ?) > This should delete what is currently there. (svn rm --force dir). > Perform something like 'svn cp ^/trunk/dir@4 dir' > (And then record the merge as happened, by not altering any mergeinfo) > Also not implemented yet... and depending on the current working copy state > possibly dangerous. > > * Just delete the tree conflict, and allow the user to apply his own changes > This is what currently happens with 'accept working'. > > I'm not sure what the mergeinfo behavior in this state should be. I just > fixed that we at least properly record the mergeinfo on 'dir', but it is > possible that not recording mergeinfo is a better option here. > > With these three options for resolving I don't see a case where recording the > mergeinfo makes complete sense for this particular testcase... accept for > allowing the merge to continue where it stopped. > > In this specific conflict that can never happen, because dir never received > actual changes in either branch or trunk... But in real working copies there > might be hundreds of changes on both branches. > > Bert Thank you for the analysis, and for your change! I agree that this is an improvement: now the directory that is conflicted gets the svn:mergeinfo property, not each of its contents. As you pointed out, my original report erroneously focused on svn:mergeinfo appearing, when the real issue is that the new svn:mergeinfo doesn't disappear (still) when the user marks the conflict resolved. (And I haven't found a way to remove it besides propdel; "svn merge --record-only ^/trunk" has no effect afaict.) My expectation as a naive user is: I initiated a merge from the root of a branch (or trunk), I told svn to merge the root of another branch (or trunk), and I resolved all reported conflicts (however complex). Unless I've explicitly told svn otherwise, I expect svn to consider this a full merge, and not create separate mergeinfo for any interior nodes. So I think it would be worth updating "svn resolve" to, by default, take action to trust the user and mark this as a full resolution. If the user needs to take an extra step or add a new parameter to get that effect, would that not feel like a regression compared with 1.7? Thanks, Pete
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Sat, Mar 14, 2015 at 4:05 PM, Pete Harlan wrote: > As you pointed out, my original report erroneously focused on > svn:mergeinfo appearing, when the real issue is that the new > svn:mergeinfo doesn't disappear (still) when the user marks the > conflict resolved. (And I haven't found a way to remove it besides > propdel; "svn merge --record-only ^/trunk" has no effect afaict.) > > My expectation as a naive user is: I initiated a merge from the root > of a branch (or trunk), I told svn to merge the root of another branch > (or trunk), and I resolved all reported conflicts (however complex). > Unless I've explicitly told svn otherwise, I expect svn to consider > this a full merge, and not create separate mergeinfo for any interior > nodes. > > So I think it would be worth updating "svn resolve" to, by default, > take action to trust the user and mark this as a full resolution. If > the user needs to take an extra step or add a new parameter to get > that effect, would that not feel like a regression compared with 1.7? A colleague argued that creating the mergeinfo for a subtree in this case (root->root merge) is a simple bug because mergeinfo says what inputs were considered to come up with the result, not just those that were used. 1. If the resulting mergeinfo is the same as for root then it's unnecessary, so the bug is that it is explicitly listed at all. 2. If the resulting mergeinfo is different than then root one then it's incorrect, because it's claiming that the subtree working copy represents the merge of a different set of branches and revisions than the root working copy it's included within. In other words, it would always be wrong for a merge to introduce explicit mergeinfo for a subtree of the merge point. This implies that the fix wouldn't be to change how resolve works, it would be for "svn merge" to not create the property on the subtree in the first place. What do you think? Thanks, Pete
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Mon, Mar 16, 2015 at 12:31 PM, Branko Čibej wrote: >> A colleague argued that creating the mergeinfo for a subtree in this >> case (root->root merge) is a simple bug because mergeinfo says what >> inputs were considered to come up with the result, not just those that >> were used. >> >> 1. If the resulting mergeinfo is the same as for root then it's >> unnecessary, so the bug is that it is explicitly listed at all. >> >> 2. If the resulting mergeinfo is different than then root one then >> it's incorrect, because it's claiming that the subtree working copy >> represents the merge of a different set of branches and revisions than >> the root working copy it's included within. >> >> In other words, it would always be wrong for a merge to introduce >> explicit mergeinfo for a subtree of the merge point. >> >> This implies that the fix wouldn't be to change how resolve works, it >> would be for "svn merge" to not create the property on the subtree in >> the first place. >> >> What do you think? > > In an ideal world, you colleague's argument would be wrong: the merge > should record what was actually merged, not what the merge command > intended. So, in cases as the one that started this discussion — when > part of the tree cannot be merged due to a conflict — the mergeinfo > should report that. Removing that not from mergeinfo should be an > integral part of the conflict resolution. > > In other words, mergeinfo should always show what /actually/ happened, > not what we wish had happened. > > -- Brane Doesn't the conflicted state of a path already indicate what actually happened? There can be no mistake about those portions of the merge being incomplete. If the svn developers do decide that introducing mergeinfo for [some? why not all?] conflicted paths is the correct scenario, I would think that that shouldn't be done until resolve knows how to clean it up. Pete
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Mon, Mar 16, 2015 at 6:08 PM, Branko Čibej wrote: >>> In an ideal world, you colleague's argument would be wrong: the merge >>> should record what was actually merged, not what the merge command >>> intended. So, in cases as the one that started this discussion — when >>> part of the tree cannot be merged due to a conflict — the mergeinfo >>> should report that. Removing that not from mergeinfo should be an >>> integral part of the conflict resolution. >>> >>> In other words, mergeinfo should always show what /actually/ happened, >>> not what we wish had happened. >>> >>> -- Brane >> Doesn't the conflicted state of a path already indicate what actually >> happened? There can be no mistake about those portions of the merge >> being incomplete. > > "Conflict" is a transient property of the working copy. "Mergeinfo" is > an attribute of the repository and is a permanent record. In most > conflict cases there are at least two ways to resolve the conflict, each > of which could produce a different answer to the question "what was merged?" The user decides "what was merged" by passing arguments to the "svn merge" command. Conflict resolution determines what files constitute the correct result of that merge. The user decides what "svn merge X Y" looks like, and only they can be the authority on that. It may involve fixing semantic conflicts, it may involve throwing away half the tree: that's up to the user. But it has no bearing on whether the result is to be considered a merge from X to Y. That is the meaning of "svn merge X Y". Conflicts are Subversion saying "I need help merging these two paths; here's how I'm confused". Solving that confusion does not change the answer to the question "what was merged?" >> If the svn developers do decide that introducing mergeinfo for [some? >> why not all?] conflicted paths is the correct scenario, I would think >> that that shouldn't be done until resolve knows how to clean it up. > > See above re ideal world ... currently it's far from ideal. One could > argue that it's better to improve some cases, rather than hope to get > them all covered in one go. > > In the case we're debating: if a normal conflict resolution leaves > unnecessary (essentially duplicate) mergeinfo, that's clearly a bug. If > it doesn't, then it's working correctly, even if not as expected, IMO. We seem to disagree on what mergeinfo is for. Here's a case where I want subtree mergeinfo: 1. Branch X merges from trunk. All mergeinfo was at root of X prior to the merge, and it is so after the merge. 2. A subtree of X merges from a subtree of branch Y. Now there's a mergeinfo at the root of X and at the root of the subtree. 3. Branch X merges from trunk again. We still need mergeinfo at X and at the subtree, because the subtree contains revisions (from Y) that X does not. 4. Branch X merges from branch Y. Subversion uses its extra info at the root of the subtree to help with the merge. At the conclusion of #4, Subversion will probably still have mergeinfo at the root of X and at the root of X's subtree; the subtree mergeinfo property is redundant now because both X and the subtree include all the same revisions of the trunk and of branch Y. In an ideal world, Subversion could remove the now-redundant subtree mergeinfo after #4; I'm not asking for that. But it would be a *bug* for it to have separate subtree info after #1. That it does, is what I'm reporting. In case this helps, here's what's motivating my report. We have a policy against subtree merges: users are only allowed to commit merges performed between branch/trunk roots. We enforce that policy by rejecting commits that add svn:mergeinfo properties to interior nodes. In my understanding, this is a correct way to enforce the policy, because subtree merges are what interior svn:mergeinfo properties are for. --Pete
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
Is it accurate then to say that Subversion may generate explicit mergeinfo whenever it decides that there is something useful to record about the set of revisions that contributed to a given node, and that svn:mergeinfo properties may appear in subnodes as part of normal Subversion merging bookkeeping, and this doesn't imply lack of a full root->root merge or other user shenanigans? I appreciate your time on this. Thanks, --Pete On Tue, Mar 17, 2015 at 8:58 AM, Pete Harlan wrote: > On Mon, Mar 16, 2015 at 6:08 PM, Branko Čibej wrote: >>>> In an ideal world, you colleague's argument would be wrong: the merge >>>> should record what was actually merged, not what the merge command >>>> intended. So, in cases as the one that started this discussion — when >>>> part of the tree cannot be merged due to a conflict — the mergeinfo >>>> should report that. Removing that not from mergeinfo should be an >>>> integral part of the conflict resolution. >>>> >>>> In other words, mergeinfo should always show what /actually/ happened, >>>> not what we wish had happened. >>>> >>>> -- Brane >>> Doesn't the conflicted state of a path already indicate what actually >>> happened? There can be no mistake about those portions of the merge >>> being incomplete. >> >> "Conflict" is a transient property of the working copy. "Mergeinfo" is >> an attribute of the repository and is a permanent record. In most >> conflict cases there are at least two ways to resolve the conflict, each >> of which could produce a different answer to the question "what was merged?" > > The user decides "what was merged" by passing arguments to the "svn > merge" command. Conflict resolution determines what files constitute > the correct result of that merge. > > The user decides what "svn merge X Y" looks like, and only they can be > the authority on that. It may involve fixing semantic conflicts, it > may involve throwing away half the tree: that's up to the user. But > it has no bearing on whether the result is to be considered a merge > from X to Y. That is the meaning of "svn merge X Y". > > Conflicts are Subversion saying "I need help merging these two paths; > here's how I'm confused". Solving that confusion does not change the > answer to the question "what was merged?" > >>> If the svn developers do decide that introducing mergeinfo for [some? >>> why not all?] conflicted paths is the correct scenario, I would think >>> that that shouldn't be done until resolve knows how to clean it up. >> >> See above re ideal world ... currently it's far from ideal. One could >> argue that it's better to improve some cases, rather than hope to get >> them all covered in one go. >> >> In the case we're debating: if a normal conflict resolution leaves >> unnecessary (essentially duplicate) mergeinfo, that's clearly a bug. If >> it doesn't, then it's working correctly, even if not as expected, IMO. > > We seem to disagree on what mergeinfo is for. Here's a case where I > want subtree mergeinfo: > > 1. Branch X merges from trunk. All mergeinfo was at root of X prior > to the merge, and it is so after the merge. > 2. A subtree of X merges from a subtree of branch Y. Now there's a > mergeinfo at the root of X and at the root of the subtree. > 3. Branch X merges from trunk again. We still need mergeinfo at X and > at the subtree, because the subtree contains revisions (from Y) that X > does not. > 4. Branch X merges from branch Y. Subversion uses its extra info at > the root of the subtree to help with the merge. > > At the conclusion of #4, Subversion will probably still have mergeinfo > at the root of X and at the root of X's subtree; the subtree mergeinfo > property is redundant now because both X and the subtree include all > the same revisions of the trunk and of branch Y. > > In an ideal world, Subversion could remove the now-redundant subtree > mergeinfo after #4; I'm not asking for that. But it would be a *bug* > for it to have separate subtree info after #1. That it does, is what > I'm reporting. > > In case this helps, here's what's motivating my report. We have a > policy against subtree merges: users are only allowed to commit merges > performed between branch/trunk roots. We enforce that policy by > rejecting commits that add svn:mergeinfo properties to interior nodes. > In my understanding, this is a correct way to enforce the policy, > because subtree merges are what interior svn:mergeinfo properties are > for. > > --Pete
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan wrote: > Is it accurate then to say that Subversion may generate explicit > mergeinfo whenever it decides that there is something useful to record > about the set of revisions that contributed to a given node, and that > svn:mergeinfo properties may appear in subnodes as part of normal > Subversion merging bookkeeping, and this doesn't imply lack of a full > root->root merge or other user shenanigans? > > I appreciate your time on this. Hi, Is that an accurate description? I'm not trying to file a bug report anymore, I'm just looking to understand the intent of this property so we can know what to expect when moving forward from 1.7. Thanks for your help, --Pete
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn wrote: > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan wrote: >> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan wrote: >>> Is it accurate then to say that Subversion may generate explicit >>> mergeinfo whenever it decides that there is something useful to record >>> about the set of revisions that contributed to a given node, and that >>> svn:mergeinfo properties may appear in subnodes as part of normal >>> Subversion merging bookkeeping, and this doesn't imply lack of a full >>> root->root merge or other user shenanigans? >>> >>> I appreciate your time on this. >> >> Hi, >> >> Is that an accurate description? I'm not trying to file a bug report >> anymore, I'm just looking to understand the intent of this property so >> we can know what to expect when moving forward from 1.7. >> >> Thanks for your help, >> > > Yes, I think it's possible that svn records mergeinfo on subnodes > (directories or files), even if there is nothing to do there. It > happens for instance when that subnode already has some explicit > mergeinfo (explicit, as opposed to inherited), because of some > previous merge. As soon as a node has explicit mergeinfo, that > explicit mergeinfo needs to be updated on every merge to the root of > the branch. > > I'm trying to explain from memory here, possibly not entirely > accurate. I think you should really start by reading this article [1] > describing the merge tracking introduced in 1.5 (it has undergone > changes and many bugfixes since then, but the underlying principles > are still the same). It explains nicely some important terms such as > 'inheritable mergeinfo', 'explicit mergeinfo', 'mergeinfo elision' > etc.. > > Also, some changes were made in 1.7 to reduce the amount of > unnecessary subtree-mergeinfo changes [2]. > > [1] https://www.open.collab.net/community/subversion/articles/merge-info.html > [2] > http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording > > -- > Johan Thank you. I don't mean updates to explicit mergeinfo, which I understand from 1.7 and prior, and I have read the docs on mergeinfo handling. In 1.8 and later I've started to see explicit svn:mergeinfo properties appearing on subtrees outside the context of user-initiated non-root merges and am trying to follow the circumstances in which they occur and whether I should stop being concerned about them. The earlier parts of this thread [1], where I was believing the new mergeinfo properties to be inadvertent (i.e., bugs) detail my confusion. I have stopped trying to tell the Subversion authors what I thought they meant to do :), and am now trying to get a solid understanding going forward. I (and others) had been inferring non-root merges when seeing explicit subtree mergeinfo (an inference informed by the articles that you cite), and believe on the basis of this thread that I have to stop doing that if I want to use 1.8 or newer. Because of the necessity to explain the rules to our developers, I was hoping for further clarification of those rules here. [1] http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260 Thanks, --Pete
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Sun, Mar 29, 2015 at 12:00 AM, Daniel Shahaf wrote: > Pete Harlan wrote on Fri, Mar 27, 2015 at 15:22:16 -0700: >> On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn wrote: >> > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan wrote: >> >> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan >> >> wrote: >> >>> Is it accurate then to say that Subversion may generate explicit >> >>> mergeinfo whenever it decides that there is something useful to record >> >>> about the set of revisions that contributed to a given node, and that >> >>> svn:mergeinfo properties may appear in subnodes as part of normal >> >>> Subversion merging bookkeeping, and this doesn't imply lack of a full >> >>> root->root merge or other user shenanigans? >> >>> >> >>> I appreciate your time on this. >> >> >> >> Hi, >> >> >> >> Is that an accurate description? I'm not trying to file a bug report >> >> anymore, I'm just looking to understand the intent of this property so >> >> we can know what to expect when moving forward from 1.7. >> >> >> >> Thanks for your help, >> >> >> > >> > Yes, I think it's possible that svn records mergeinfo on subnodes >> > (directories or files), even if there is nothing to do there. It >> > happens for instance when that subnode already has some explicit >> > mergeinfo (explicit, as opposed to inherited), because of some >> > previous merge. As soon as a node has explicit mergeinfo, that >> > explicit mergeinfo needs to be updated on every merge to the root of >> > the branch. >> > >> > I'm trying to explain from memory here, possibly not entirely >> > accurate. I think you should really start by reading this article [1] >> > describing the merge tracking introduced in 1.5 (it has undergone >> > changes and many bugfixes since then, but the underlying principles >> > are still the same). It explains nicely some important terms such as >> > 'inheritable mergeinfo', 'explicit mergeinfo', 'mergeinfo elision' >> > etc.. >> > >> > Also, some changes were made in 1.7 to reduce the amount of >> > unnecessary subtree-mergeinfo changes [2]. >> > >> > [1] >> > https://www.open.collab.net/community/subversion/articles/merge-info.html >> > [2] >> > http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording >> > >> > -- >> > Johan >> >> Thank you. I don't mean updates to explicit mergeinfo, which I >> understand from 1.7 and prior, and I have read the docs on mergeinfo >> handling. In 1.8 and later I've started to see explicit svn:mergeinfo >> properties appearing on subtrees outside the context of user-initiated >> non-root merges and am trying to follow the circumstances in which >> they occur and whether I should stop being concerned about them. >> >> The earlier parts of this thread [1], where I was believing the new >> mergeinfo properties to be inadvertent (i.e., bugs) detail my >> confusion. I have stopped trying to tell the Subversion authors what >> I thought they meant to do :), and am now trying to get a solid >> understanding going forward. >> >> I (and others) had been inferring non-root merges when seeing explicit >> subtree mergeinfo (an inference informed by the articles that you >> cite), and believe on the basis of this thread that I have to stop >> doing that if I want to use 1.8 or newer. Because of the necessity to >> explain the rules to our developers, I was hoping for further >> clarification of those rules here. >> > > I think it's fairly accurate to say that a merge will only create/update > svn:mergeinfo on: > > 1. The merge target (i.e., usually the root of some branch). > > 2. Descendants of #1 that already have svn:mergeinfo properties. > > 3. Descendants of #1 that have a child or sibling that is switched or > excluded by authz (called "server-excluded" in the code) or excluded by > depth setting or not the same revision (in the 'svn info | grep > ^Revision:' sense) as its parent. > > Put another way, if you have a uniform-revision working copy with no > subtrees that are (switched or excluded-by-depth or server-excluded), > then svn:mergeinfo changes will only occur on the target root and on > files/dirs that already had svn:mergeinfo properties before the merge > started. > > Daniel > >> [1] http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260 >> >> Thanks, >> >> --Pete That was my understanding also, but this isn't the behavior in 1.8 (see this thread). I reported the change as a bug, but Subversion's maintainers say that the new behavior is normal (which is what this thread has been about). Hence my attempt to clarify what the rules are, or whether I need to stop caring about explicit mergeinfo (or stay with 1.7).
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Tue, Mar 31, 2015 at 8:05 AM, Julian Foad wrote: > Hello. > > Firstly I'd like to say thank you, Pete, for bringing up this issue > and discussing it so clearly. > > I had a think about this the other day and chatted with the others on IRC [1]. > > I picked this old email from this thread to reply to, as it's got me > in the CC and is as good a one as any to reply to. > > Much of this has been said already, but here's my 'take' on the problem. > > > On 2015-03-16, Pete Harlan wrote: >> On 2015-03-14, Pete Harlan wrote: >>> My expectation as a naive user is: I initiated a merge from the root >>> of a branch (or trunk), I told svn to merge the root of another branch >>> (or trunk), and I resolved all reported conflicts (however complex). >>> Unless I've explicitly told svn otherwise, I expect svn to consider >>> this a full merge, and not create separate mergeinfo for any interior >>> nodes. > > Yes, I completely agree. The user has requested a full merge and > sorted out all the physical and semantic conflicts. The mergeinfo is > meant to record the intent of the merge, as you correctly argued, > rather than to record exactly where the physical content changes were > made in the target branch in order to achieve the desired result [2]. > Therefore the merge should be recorded, in the end, as a complete > merge, with no subtree mergeinfo needed. > > There are two or three things going on. (I'm going to be critical of > Subversion here.) > > 1. The user should always have the choice to record a subtree as > 'merged' or as 'not merged'. Subversion currently doesn't make this > choice easily available, and doesn't clearly report or document what > it's doing, in all the cases that can occur during a merge such as > > - a conflict occurs > - skipped because subtree is missing, obstructed, or still > conflicted from an earlier merge > - subtree is switched > > and across different operations on the subtree, such as > > - revert changes to subtree > - copy/move/rename the subtree > > In some of these cases it records mergeinfo indicating 'merged', and > in other cases indicating 'not merged'. > > 2. Subtree mergeinfo was never designed to be an absolute indicator > that a subtree merge had been done. In other words, there was no > specific rule that a complete tree merge must result in no subtree > mergeinfo. After 1.5 was released and some work flows resulted in lots > of subtree mergeinfo (especially, I remember, copies added subtree > mergeinfo), there was a succession of refinements aimed at reducing > the number of nodes having subtree mergeinfo. > > When Subversion creates (or fails to elide) unnecessary subtree > mergeinfo, we classify that as suboptimal performance but not an > outright bug. > > In fact, the plan for eliding mergeinfo is not simply "always elide > any unnecessary explicit mergeinfo". In some cases it's more like > "elide unnecessary mergeinfo if we're touching that node anyway, but > don't touch other nodes just to elide their mergeinfo". In other > words, trying to minimize the number of changes to be committed. I > don't know the details of when we do what. > > 3. The Working Copy and its user interface doesn't keep track of what > merge(s) you have done, it just tracks the resulting mergeinfo > properties. As a consequence, for example, after doing a merge to the > root of the WC if you try to commit a subtree, it won't notice that > actually to commit the subtree along with the subtree's mergeinfo it > needs to put a mergeinfo property on the subtree. > > What you will find is that the merge implementation has not carefully > followed a consistent set of rules or a 'mental model'. There have > been rules and mental models but they have not been formally > identified and kept consistent. I'd love to be able to point you to > the rules as documented, but unfortunately can't. And there are still > cases where it does something that's clearly wrong or inconsistent. > > What to do? > > In the case you identified, I certainly agree it's bad behaviour, not > what we want. But it's not easy to know exactly which cases need > fixing -- or if "fixing" this case would make it inconsistent with > other cases -- without first cataloguing the existing behaviour over > all or most cases. If somebody wants to work on fixing this case, > that's fine, what I'm saying is I'm more interested in figuring out > the bigger solution. > > Pete, you seem to have a good grasp of
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad wrote: > Pete Harlan wrote: ... >> If you have suggestions for how I could further help this issue along, >> please let me know. And thanks again very much for your time. > > It would help to catalogue the various cases. Maybe start with an > premise that a whole tree merge should not generate any subtree > mergeinfo and start finding the exceptions that currently occur. I wrote a list of cases I could think of to test, and tested them against 1.8.13. Of the cases I considered and tested, the subtree mergeinfo appeared if and only if a *directory* node was part of a tree conflict (regardless of what it conflicted with). "PASSED" here means no subtree merge info was created, and "FAILED" means it was created. In all cases, "svn resolve --accept=working " was run prior to looking for subtree mergeinfo. PASSED: dir-add-delete.sh (One side adds a dir, the other added and deleted a dir of the same name) PASSED: dir-delete-delete.sh (Both sides deleted a common dir.) PASSED: file-add-add.sh (Both sides added a file with the same name.) PASSED: file-add-delete.sh (One side added a file, the other added and deleted the file.) PASSED: file-copy-add.sh (One side added a file via copy, the other via creating a new file.) PASSED: file-delete-delete.sh (Both sides deleted the same file.) PASSED: file-edit-delete.sh (One side edited a file, the other deleted it.) PASSED: file-edit-edit.sh (Both sides edited a file in conflicting ways.) PASSED: no-conflict.sh (Clean merge.) FAILED: dir-add-add.sh (Dir of same name added to both sides.) FAILED: dir-copy-add.sh (Same, only one was added via copy the other as new.) FAILED: dir-file-add-add.sh (File added to one side, dir of same name added to other.) Current trunk fails the same tests. All tests pass with 1.7.20 and 1.6.23. My scripts are Bash scripts similar to the script I originally posted to this thread. I can share them if you think that would be useful, or I'm happy to rerun them against other versions upon request. > Another way to help would be to think about how the client could > present the "WC is in a merged state" notion, and how that would > affect various operations. Just assume that we can implement it, and > imagine how it should behave in order to be useful. Is there a hard > dividing line between "is" and "is not" in a "merged" state for the > whole WC -- what if we *want* to merge subtrees separately? Does this > "state" need more degrees of subtlety in some other way too? When the WC is in a merged state, doesn't it necessarily contain modifications to the merge-root svn:mergeinfo property? It seems reasonable to me to have Subversion error out from initiating a new merge if it is currently in the middle of a merge (as identified by a modified svn:mergeinfo property), with a message like "You are in the middle of merging to ; please complete that before merging again or revert it with <...>". Any modification to other nodes' mergeinfo would be done only by "resolve", which by default would resolve as a "full merge" as initiated by the user (and thus not add explicit mergeinfo), and if you want to handle merges that omit interior nodes from the merge (why?) then you would do so with a new option to resolve, something like "svn resolve --accept=omit-from-merge ". If *that* command created interior mergeinfo, that would probably coincide with user expectation. I am aware that my analysis is naive regarding both Subversion's implementation and the universe of potential use-cases, but for the way I use Subversion this seems reasonable to me. I'm also wondering if something could be done more expediently: Is Subversion doing anything useful with the subtree mergeinfo that appeared in 1.8? If not, then perhaps it could disappear until the feature it's part of is more fleshed out (i.e., until a solution that includes ways for the user to pass their intent to "resolve" is added). Again, I don't know Subversion internals so maybe Subversion is doing something useful with that information that I'm unaware of. Thank you for your time, --Pete
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Fri, Apr 10, 2015 at 6:40 PM, Branko Čibej wrote: > On 11.04.2015 02:01, Pete Harlan wrote: >> On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad >> wrote: >>> Pete Harlan wrote: >> ... >>>> If you have suggestions for how I could further help this issue along, >>>> please let me know. And thanks again very much for your time. >>> It would help to catalogue the various cases. Maybe start with an >>> premise that a whole tree merge should not generate any subtree >>> mergeinfo and start finding the exceptions that currently occur. >> I wrote a list of cases I could think of to test, and tested them >> against 1.8.13. >> >> Of the cases I considered and tested, the subtree mergeinfo appeared >> if and only if a *directory* node was part of a tree conflict >> (regardless of what it conflicted with). "PASSED" here means no >> subtree merge info was created, and "FAILED" means it was created. >> >> In all cases, "svn resolve --accept=working " was run >> prior to looking for subtree mergeinfo. >> >> PASSED: dir-add-delete.sh (One side adds a dir, the other added and >> deleted a dir of the same name) >> PASSED: dir-delete-delete.sh (Both sides deleted a common dir.) >> PASSED: file-add-add.sh (Both sides added a file with the same name.) >> PASSED: file-add-delete.sh (One side added a file, the other added >> and deleted the file.) >> PASSED: file-copy-add.sh (One side added a file via copy, the other >> via creating a new file.) >> PASSED: file-delete-delete.sh (Both sides deleted the same file.) >> PASSED: file-edit-delete.sh (One side edited a file, the other deleted it.) >> PASSED: file-edit-edit.sh (Both sides edited a file in conflicting ways.) >> PASSED: no-conflict.sh (Clean merge.) >> >> FAILED: dir-add-add.sh (Dir of same name added to both sides.) >> FAILED: dir-copy-add.sh (Same, only one was added via copy the other as >> new.) >> FAILED: dir-file-add-add.sh (File added to one side, dir of same name >> added to other.) >> >> Current trunk fails the same tests. All tests pass with 1.7.20 and 1.6.23. >> >> My scripts are Bash scripts similar to the script I originally posted >> to this thread. I can share them if you think that would be useful, >> or I'm happy to rerun them against other versions upon request. > > > It would be wonderful if you could share those scripts; it saves time > when everyone uses the same test scripts to discuss behaviour, and we'd > surely like to incorporate any new scenario into our test suite. Attached. Disclaimer: they were written to optimize the time spent initially writing them, not reading or maintaining them :-) There's a lot of copy+pasting here, inconsistent style, etc. I looked at writing proper tests using your Python framework but wasn't able to take the time to learn that setup. Also, written for a Linux+bash environment; not tested anywhere else. There's a README describing how to run them, but it's basically "runAll.sh >>> Another way to help would be to think about how the client could >>> present the "WC is in a merged state" notion, and how that would >>> affect various operations. Just assume that we can implement it, and >>> imagine how it should behave in order to be useful. Is there a hard >>> dividing line between "is" and "is not" in a "merged" state for the >>> whole WC -- what if we *want* to merge subtrees separately? Does this >>> "state" need more degrees of subtlety in some other way too? >> When the WC is in a merged state, doesn't it necessarily contain >> modifications to the merge-root svn:mergeinfo property? It seems >> reasonable to me to have Subversion error out from initiating a new >> merge if it is currently in the middle of a merge (as identified by a >> modified svn:mergeinfo property), with a message like "You are in the >> middle of merging to ; please complete that before >> merging again or revert it with <...>". > > This does sound like a logical approach. The problem is that what looks > like a single merge from the user's perspective can actually be a series > of merges, where each merge depends on the results (including locally > modified mergeinfo) of the previous merge. Consider the simplest case, > with B branched from A in r5, and r10 cherry-picked from B to A. A full > merge of r15 from B to A will actually be split into two merges of two > revision ranges: [6..9] and [11..15], skipping the already-merged r10. When I say t
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Mon, Apr 13, 2015 at 9:31 AM, Julian Foad wrote: > Pete Harlan wrote: >> Julian Foad wrote: > [...] >>> Another way to help would be to think about how the client could >>> present the "WC is in a merged state" notion, and how that would >>> affect various operations. Just assume that we can implement it, and >>> imagine how it should behave in order to be useful. Is there a hard >>> dividing line between "is" and "is not" in a "merged" state for the >>> whole WC -- what if we *want* to merge subtrees separately? Does this >>> "state" need more degrees of subtlety in some other way too? >> >> When the WC is in a merged state, doesn't it necessarily contain >> modifications to the merge-root svn:mergeinfo property? > > Not necessarily. Not if I ran a subtree merge, such as > > svn merge ^/branches/source-branch/subtree ./subtree But in this example, ./subtree is the merge root, and it's subtree's mergeinfo that is modified (in 1.8.13), so this agrees with what I suggested. (I may be using "merge root" in a nonstandard way: I mean the points in the WC and the source URL that are being merged.) >> It seems >> reasonable to me to have Subversion error out from initiating a new >> merge if it is currently in the middle of a merge (as identified by a >> modified svn:mergeinfo property), with a message like "You are in the >> middle of merging to ; please complete that before >> merging again or revert it with <...>". > > Sometimes, particularly if I know there's a big change or an intrusive > change among all the changes I want to merge from a given source > branch, it is nice to be able to merge a portion of all the source > changes I really want (a restricted revision range and/or a restricted > subtree), and resolve conflicts and check it's looking ok, and then > merge another portion or all the rest of the changes. That can help me > to deal with complex conflicts better. > > But in general, I expect most people do most merges in one go, and > what you suggest might indeed be helpful. We just might want a bypass > for the intentional cases. That's no problem, we can have a bypass. That is a case I hadn't considered, but it sounds reasonable and I think a bypass would make sense here. >> Any modification to other nodes' mergeinfo would be done only by >> "resolve", which by default would resolve as a "full merge" as >> initiated by the user (and thus not add explicit mergeinfo), and if >> you want to handle merges that omit interior nodes from the merge >> (why?) > > I might want to omit part of the tree from the merge if, for example, > the tree consists of one subtree 'src' containing lots of source code, > and another 'doc' containing lots of documentation, and the merge > turns out to have lots of changes and lots of conflicts in both areas, > and I decide that instead of completing all the conflict resolution in > both subtrees I'd rather concentrate on getting everything under 'src' > properly merged and leave the 'doc' for later. I might want to commit > this result, a result that says everything except the content of 'doc' > is merged, so that I or someone else can then merge the 'doc' subtree > later. Does that make sense, at least hypothetically? Yes, that makes a lot of sense. It's a way to collaborate on a merge, with the downside being that commits are made that represent an inconsistent state of the code (but that may be the best solution in some cases). --Pete >> then you would do so with a new option to resolve, something >> like "svn resolve --accept=omit-from-merge ". If *that* command >> created interior mergeinfo, that would probably coincide with user >> expectation. > > Yes, that sort of thing sounds reasonable. > >> I am aware that my analysis is naive regarding both Subversion's >> implementation and the universe of potential use-cases, but for the >> way I use Subversion this seems reasonable to me. >> >> I'm also wondering if something could be done more expediently: Is >> Subversion doing anything useful with the subtree mergeinfo that >> appeared in 1.8? If not, then perhaps it could disappear until the >> feature it's part of is more fleshed out (i.e., until a solution that >> includes ways for the user to pass their intent to "resolve" is >> added). Again, I don't know Subversion internals so maybe Subversion >> is doing something useful with that information that I'm unaware of. > > Hmm, I'm not sure about that. > > - Julian
Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
On Mon, Apr 13, 2015 at 10:58 AM, Pete Harlan wrote: >> My scripts are Bash scripts similar to the script I originally posted >> to this thread. I can share them if you think that would be useful, >> or I'm happy to rerun them against other versions upon request. ... > Attached. Disclaimer: they were written to optimize the time spent > initially writing them, not reading or maintaining them :-) There's a > lot of copy+pasting here, inconsistent style, etc. I looked at > writing proper tests using your Python framework but wasn't able to > take the time to learn that setup. > > Also, written for a Linux+bash environment; not tested anywhere else. > > There's a README describing how to run them, but it's basically "runAll.sh Updated version attached, which doesn't require the user to issue a full path to the runAll.sh script. Grr... --Pete mergeinfo-tests.tar.gz Description: GNU Zip compressed data
Re: svn:mergeinfo is acting strange
Hi, If you're using Subversion 1.8, you may find this thread relevant: http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260 It describes specific instances in which Subversion 1.8 (and later) add mergeinfo to nodes. The mergeinfo there may be safely removed. --Pete On Thu, Jun 25, 2015 at 8:01 AM, Stefan Hett wrote: > Hi Chris, > >> Hi, >> >> we've been using SVN for a large in-house project for a number of years >> and the longer time goes by, the more strange the svn:mergeinfo properties >> behave. I don't know if the "issues" are completely expected, if our >> repository somehow has ended up in a state that is unwanted or if there's >> something bug somewhere. >> >> What happens: >> Whenever someone merges a branch onto the trunk, there are approximately >> 100 files/directories that get added mergeinfo despite these files (or files >> under them) not being affected by the commit. That the root directory of the >> trunk should be modified makes perfect sense to me, but if my merge only >> affects src/foo/bar.txt, why does it then have to set mergeinfo on e.g. >> test/some/untelated/thing.txt? >> It seems to be the same set or files/dirs that always get tagged with >> additional information, so I suspect that some previous merge has made these >> specific files add all future mergeinfos into them, while other files that >> didn't get this strangeness stay unaffected. E.g. I have two source files in >> the same directory: File1 has 367 lines of mergeinfo (367 different branch >> merges, that is), file File2 has 0. And both these files are equally old, so >> it makes no sense that they should differ that way. >> >> Is this expected or has our repository become overzealous? >> If the latter: can I "fix" this situation by manually deleting the >> mergeinfo from files "further down in the tree"? And if I do that, how badly >> will upcoming branch merges be affected? >> >> This isn't a major issue, but there have been cases where we've had >> conflicts inside the mergeinfo in these "special files" which has been sort >> of difficult to resolve for some committers. It is also quite annoying that >> every time we do "svn update" after a merge, we get 100+ lines of updates >> even if just one file has been modified (especially annoying in tools like >> subclipse). >> >> TIA, >>Chris > > > We are facing exactly the same issue. I just got through dealing with this > on our case using a tool written by the SVN developer Stefan Fuhrmann to get > rid of redundant/unnecessary mergeinfo entries. It can be downloaded from > the svn-mergeinfo-normalizer branch in the SVN repository. The tool is > located under tools/client-side/svn-mergeinfo-normalizer. The branch readme > provides some basic information about what the tool does and how it can be > utilized. > > In principle it provides the following functionality (all done on a WC): > - analyzing the mergeinfo and reporting whether certain nodes can be > combined (and if not, what presents it from being combined) > - normalize the mergeinfo (basically removing redundant mergeinfo entries on > nodes) > - combine-ranges to combine the recorded revisions to a shorter but > semantically equal representation > - clear-obsoletes to drop mergeinfos for branches which no-longer exist on > HEAD > > Since you asked: I guess in most cases the reason for recording additional > mergeinfos is because (for some other reason) you ended up with adding > mergeinfos on a subnode (for instance test/some/unrelated/thing.txt. > As per definition of mergeinfos once a node (like thing.txt in ur case) > contains mergeinfo, it needs to contain all the relevant mergeinfo in its > own node. This is due to performance reasons as far as I understand it, so > that if u want to determine which revisions got merged into a node, SVN only > has to check out this one mergeinfo entry, rather than going up the tree to > determine which things got merged into this one. > > The good question here is why does it even keep record for revisions the > node is not impacted by. I asked the same question in February already on > this list (see: inconsistency between mergeinfo records). As far as I > understand this is done atm to keep the application design simple. There are > cases where the additional mergeinfo is required on nodes (for instance when > adding a new file in a directory, the record needs to be kept on the > directory node so the mergeinfo is correct). Effectively things could be > improved (and as far as I've read here, it's on the radar for a later > version), but the current behavior is as it stands right now. > > If u're running under Windows and want to give the svn-mergeinfo-normalizer > tool a try, I could send u the executable I've compiled and am using myself > here. > > Regards, > Stefan
Re: 1.9 - Can't resolve to 'mine full' option for binary file conflict
On Mon, Sep 14, 2015 at 3:03 AM, Bert Huijben wrote: >> On 9/14/2015 7:56 AM, Daniel Becroft wrote: >> > Hi guys, >> > >> > >> > I've just upgraded to SVN 1.9. One of the first things I noticed is >> > that when a binary file conflict is raised during an SVN update, I can >> > no longer use the 'mine-full' option to resolve. >> > >> > The only options I have are: (r) working and (tf) theirs-full. ... > The Subversion developer responsible for choosing this UI determined that it > didn't make much sense to offer two different resolve options with exactly the > same result. Perhaps a user or script wants to resolve a merge of some files in favor of their versions, regardless of whether the file is binary. You're now requiring that user or script to consider binary-ness in order to use the UI, no? --Pete
