svn 1.5 merge -c revision and svn diff/log confusion

[Karol Szkudlarek]

Hello!

I have a production system repository which were about half year ago
migrated from 1.3.x to 1.5.x server. We also do svnadmin dump/load
procedure to full migrate to 1.5. And nothing all.

In 1.3 and we used 'svn merge' subcommand with great success. But now I
noticed something that make me doubt in new subversion mergetracking
feature.

Please look and example of svn log from my repository which was obtained
after executing merge from branch->branch and svn commit on branch.


$ cd src/sql
$ svn merge -c 52829
https://mik-svn.mikronika.com.pl/var/svn/rv/branches/rv_qt_2_9/prg/src/sql

and after it I commited the changes (of course I don't have any local
modification on the branch) and I do svn log -v -r 52851 -g I saw that
my commit contains "more" that original commit r52829. After svn diff
I saw that commit r52851 contains mergeinfo "mess" for a random files
and random directories of sql/. So could anybody help me in interpreting
such sitiuation?

In r52829 was only change in rdzexp.ini.xml file but in
r52851 I have "something" more which provides me a lot of confusion and
I do ask myself whether I perform svn merge correctly. I expected svn
log/diff to show me only changes in this one file rdzexp.ini.xml.


This is only one example, beacuse I do more svn merges I noticed such
differences betweeen contents of original commit and commit after merge
which I can't understand.


$ svn log -v -r 52851 -g

r52851 | karols | 2009-10-28 12:01:39 +0100 (Śr, 28 paź 2009) | 6 lines
Changed paths:
    M /branches/rv_qt_2_9_16/prg/src/sql
    M
/branches/rv_qt_2_9_16/prg/src/sql/excel/StronaTytulowaRaportPodstawowy.xls.tmpl
    M
/branches/rv_qt_2_9_16/prg/src/sql/excel/StronaTytulowaRaportSkrocony.xls.tmpl
    M /branches/rv_qt_2_9_16/prg/src/sql/oracle
    M /branches/rv_qt_2_9_16/prg/src/sql/oracle/se_manager
    M /branches/rv_qt_2_9_16/prg/src/sql/toricfg/patterns/rdzexp.ini.xml


Tori Patterns: dodany kom.tylkoZmiana do rdzexp.ini.xml

merge 29.52829.


------------------------------------------------------------------------
r52829 | huberts | 2009-10-28 10:12:53 +0100 (Śr, 28 paź 2009) | 2 lines
Changed paths:
    M /branches/rv_qt_2_9/prg/src/sql/toricfg/patterns/rdzexp.ini.xml
Merged via: r52851

Tori Patterns: dodany kom.tylkoZmiana do rdzexp.ini.xml

------------------------------------------------------------------------


--
Karol Szkudlarek
Mikronika
ul. Wykopy 2/4
60-001 POZNAÑ
tel. [phone]
fax [phone]
e-mail karol@...

Please consider your environmental responsibility.
Before printing this e-mail message, ask yourself
whether you really need a hard copy.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2412157

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Tyler Roscoe]

On Wed, Oct 28, 2009 at 04:17:25PM +0100, Karol Szkudlarek wrote:
> modification on the branch) and I do svn log -v -r 52851 -g I saw that
> my commit contains "more" that original commit r52829. After svn diff
> I saw that commit r52851 contains mergeinfo "mess" for a random files
> and random directories of sql/. So could anybody help me in interpreting
> such sitiuation?

This question is asked about once a week. Search the archives for plenty
of answers and options about how to proceed.

tyler

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2412164

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Karol Szkudlarek]

Tyler Roscoe pisze:
> On Wed, Oct 28, 2009 at 04:17:25PM +0100, Karol Szkudlarek wrote:
>> modification on the branch) and I do svn log -v -r 52851 -g I saw that
>> my commit contains "more" that original commit r52829. After svn diff
>> I saw that commit r52851 contains mergeinfo "mess" for a random files
>> and random directories of sql/. So could anybody help me in interpreting
>> such sitiuation?
>
> This question is asked about once a week. Search the archives for plenty
> of answers and options about how to proceed.

1) maybe... but I try to look archives from 06.2008, 07.2008 for finding
answers and those mails were not satisfactory for me. Next I'm not
reading day by day users@ mailing list. But maybe I should slowly dig
into next month of users@...

For example thread http://svn.haxx.se/users/archive-2008-07/0932.shtml
was interesting but at the end was asking next question from the
author... and problem seems open.


2) If this question is such often asked maybe developers of subversion
should nominate this problem and answer officially in their subversion
FAQ? I read a FAQ and release notes and nothing find about.

3) If something is repeadedly asked so maybe is to difficult and too odd
to understand for a usual subversion user of <1.5.


Regards,
Karol Szkudlarek

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2412232

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Stein Somers]

As far as I get the question right, I have not seen many useful answers in 6
weeks. If the question is a FAQ, we have come at the point that the most
frequently posted reply is that it was answered before, without a reference
to the earlier answer, which then turns up in searches as answer, making it
even harder to find the truth.

If you have enough intellectual capacity, try to understand all of
http://www.collab.net/community/subversion/articles/merge-info.html

My own mergeinfo for dummies like myself is:

Some svn versions near 1.5 write spurious svn:mergeinfo attributes with
an empty value. The empty value does have a meaning apparently, but it
happens when you don't intend to exploit that meaning. Some actions even copy
all revision properties of the working copy top folder to files, including
bugtraq and svn:ignore properties. Duh?

Anyway, when merging later, each svn:mergeinfo value grows - which makes
sense if the svn:mergeinfo were intended to be. Every commit grows. Worse,
every update of a working copy updates files: the svn:mergeinfo properties of
the file are updated, the file contents stay the same, but unfortunately the
last-modified timestamp is touched, so your build system assumes the file has
changed.

Luckily, since we are dummies and no hard core subverters, we only ever merge
complete working copies and commit them all at once. We don't fool around
with shallow checkouts or switched working copies. We have no
"non-inheritable mergeinfo ranges" (with an asterisk). So we can put this all
past us by simply deleting all svn:mergeinfo below the working copy top. In
an updated, unchanged working copy:

        svn propdel svn:mergeinfo -R
        svn revert . # undelete mergeinfo on the top folder
        svn commit -m "Removed stray mergeinfo"

After that you could try to avoid the empty svn:mergeinfo being committed
again, or even write a pre-commit hook to make sure. Or just do it again when
needed.

Once you upgrade to version 1.6 or so, you never need to fix matters like
this again.

--
Stein

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2412783

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Karol Szkudlarek]

Thank you for the explantation. It helps me understand 1.5.x mergeinfo.

Maybe developers of subversion should write
that 1.5.x is not recommended for using in
a production system.

Regards,
Karol

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2412991

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Bob Archer]

> Thank you for the explantation. It helps me understand 1.5.x mergeinfo.
>
> Maybe developers of subversion should write
> that 1.5.x is not recommended for using in
> a production system.

We've been using 1.5 in production all year without problems.

Two points.

1. The merge data doesn't hurt anything (some perf issues that are to be resolved in 1.7). As someone else already said if you merge from the root project folder the merge info won't propagate to all the child files and folders. In other words always merge to /trunk as the target from the branches root.

2. If you are merging in from a temporary branch that will be deleted, you don't really need the merge info on trunk. So after you do your merge, revert all the mergeinfo before you commit the merge.

BOb

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413009

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Bob Archer]

> > Thank you for the explantation. It helps me understand 1.5.x
> mergeinfo.
> >
> > Maybe developers of subversion should write
> > that 1.5.x is not recommended for using in
> > a production system.
>
> We've been using 1.5 in production all year without problems.
>
> Two points.
>
> 1. The merge data doesn't hurt anything (some perf issues that are to
> be resolved in 1.7). As someone else already said if you merge from the
> root project folder the merge info won't propagate to all the child
> files and folders. In other words always merge to /trunk as the target
> from the branches root.
>
> 2. If you are merging in from a temporary branch that will be deleted,
> you don't really need the merge info on trunk. So after you do your
> merge, revert all the mergeinfo before you commit the merge.
>

3. Rather than doing branches and merging create a patch from your work PC, and email it to your home PC, and then vice versa.

BOb

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413012

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Stein Somers]

Karol Szkudlarek wrote:
 > Maybe developers of subversion should write
 > that 1.5.x is not recommended for using in
 > a production system.

If you're looking for perfect software, you'll have to write it yourself. The
spuriously generated mergeinfo is a minor little bug that you can easily work
around. Your data is safe, nothing crashes, nothing hangs.

I'm not even sure it is a bug at all. It may be something dummies like us do
wrong. Like commit, forget to update, merge. Or resolve a conflict in some
unintended way. But at least one other list member has mentioned it's a bug.
And it never happens in the production environment I work in since svn 1.6.

Bob Archer wrote:
> 1. The merge data doesn't hurt anything

People are confused and write to the list, so some merge data is hurting them
a little.

> if you merge from the root project folder the merge info won't propagate

The heart of the thread is that this is not true for some 1.5 version(s):
some children get (initially empty) explicit mergeinfo attributes, out of the
blue.

--
Stein

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413033

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Stein Somers]

In other words, to make way Bob's method 1. work, without interference by
spurious mergeinfo, you want everyone to avoid committing spurious mergeinfo
below the working copy but still preserve the real mergeinfo on the top folder.

How can you do that? What I actually did at the time was:

        svn propget svn:mergeinfo . > some_temporary_file
        svn propdel svn:mergeinfo -R
        svn propset svn:mergeinfo . -F some_temporary_file

Is there a neater way? Something like

        svn propdel svn:mergeinfo --depth infinity_but_skip_top_folder

--
Stein

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413043

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Stein Somers]

I digged up notes which I was going to turn into a bug report but never did.
The source of the stray mergeinfo we experienced was not merging, but copying
(or renaming or moving).

A simple WC -> WC copy of a file adds an empty svn:mergeinfo property to the
target, as well as other properties apparently copied from the working folder
top. Both the 1.5 command line client and 1.5.1 TSVN do this systematically,
as far as I can tell.

I can't find a specific issue now, but issues 3367 and 3068 do suggest that
copy in 1.5 stuck its nose where it didn't belong.

--
Stein

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413096

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Stein Somers]

I digged up notes which I was going to turn into a bug report but never did.
The source of the stray mergeinfo we experienced was not merging, but copying
(or renaming or moving).

A simple WC -> WC copy of a file adds an empty svn:mergeinfo property to the
target, as well as other properties apparently copied from the working folder
top. Both the 1.5 command line client and 1.5.1 TSVN do this systematically,
as far as I can tell.

I can't find a specific issue now, but issues 3367 and 3068 do suggest that
copy in 1.5 stuck its nose where it didn't belong.

--
Stein

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413097

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Karol Szkudlarek]

> Karol Szkudlarek wrote:
>  > Maybe developers of subversion should write
>  > that 1.5.x is not recommended for using in
>  > a production system.
>
> If you're looking for perfect software, you'll have to write it yourself. The
> spuriously generated mergeinfo is a minor little bug that you can easily work
> around. Your data is safe, nothing crashes, nothing hangs.
>
> I'm not even sure it is a bug at all. It may be something dummies like us do
> wrong. Like commit, forget to update, merge. Or resolve a conflict in some
> unintended way. But at least one other list member has mentioned it's a bug.
> And it never happens in the production environment I work in since svn 1.6.

Ok, you right, but:

1) As we see on mailing lists this little bug/or feature is seems be surprise for
<1.5 svn users. And in release notes or known
issues are nothing to about it.

2) I insist to svn developers, please give users (not matter dummies or power users) clear information (for example in FAQ Subversion) what I should expect after using the same commands with new toys like >=1.5 and svn merge.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413769

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].