getting rid of the old svk:merge properties?

[Christian Boos]

Hello,

I'd like to remove the various svk:merge properties scattered in the tree.
It contains out-dated information and AFAIK, no one actively developing
on Trac still uses svk.

Ok to delete them?

-- Christian

[Remy Blank]

Christian Boos wrote:
> Ok to delete them?

+1

-- Remy

[Jeroen Ruigrok van der Werven]

-On [20090624 10:18], Christian Boos (cb...@neuf.fr) wrote:
>Ok to delete them?

Go right ahead.

--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Mayoi nagara demo ii aruki dashite...

[Christian Boos]

Jeroen Ruigrok van der Werven wrote:
> -On [20090624 10:18], Christian Boos (cb...@neuf.fr) wrote:
>
>> Ok to delete them?
>>
>
> Go right ahead.
>
>

Ok, did so in r8296 and that change was propagated to the other branches
in later merge changesets:
- http://trac.edgewall.org/changeset/8297
- http://trac.edgewall.org/changeset/8298
- http://trac.edgewall.org/changeset/8299

Speaking of those, now that we're all(?) using Subversion 1.5/1.6 "svn
merge" and its svn:mergeinfo, the use of the svnmerge.py script has
become a bit redundant. One nice feature of the script vs. the command
was that with svnmerge you could explicitly record a change as being
"blocked", whereas with the command, you have to fake the merge (using
--record-only, as shown in r8297 above). But that's a minor thing.

Now I wonder if it's a good idea to keep using both "svnmerge" and "svn
merge" for tracking merge information (as I did in r8297 and r8298), or
if it's not time to use exclusively "svn merge" and forget about
svnmerge.py?

-- Christian

[Emmanuel Blot]

> Now I wonder if it's a good idea to keep using both "svnmerge" and "svn
> merge" for tracking merge information (as I did in r8297 and r8298), or
> if it's not time to use exclusively "svn merge" and forget about
> svnmerge.py?

I'd vote in favor of the native svn merge solution

We just have to check that every one is using SVN 1.5.5 min (and not SVN 1.6.0)
It's a pity the client version cannot be validated with a hook script.

[Remy Blank]

Christian Boos wrote:
> One nice feature of the script vs. the command
> was that with svnmerge you could explicitly record a change as being
> "blocked", whereas with the command, you have to fake the merge (using
> --record-only, as shown in r8297 above). But that's a minor thing.

It means that we lose information compared to the svnmerge.py script,
namely the revisions that we explicitly didn't want to merge. OTOH, the
most useful information given by the merge properties is the revisions
eligible for merging. I have never gone back in the repository history
to find out why a revision was blocked, so I don't mind.

I'll follow with the majority.

-- Remy

[Noah Kantrowitz]

Personally I still prefer svnmerge.py if nothing else because it
generates the log messages nicely. Also svn merge is very messy and
tends to little properties all over the codebase that get very annoying.

--Noah

[Remy Blank]

Noah Kantrowitz wrote:
> Personally I still prefer svnmerge.py if nothing else because it
> generates the log messages nicely.

With the recent addition of the svn:mergeinfo property renderers, the
full log message will not be necessary anymore, because the modification
of the svn:mergeinfo property is linkified, so you can get a log view of
all the merged revisions with a single click.

> Also svn merge is very messy and
> tends to little properties all over the codebase that get very annoying.

IIRC, Manu mentioned that this was a bug in the early 1.6.x versions,
which seems to be fixed in 1.6.2.

-- Remy

[Emmanuel Blot]

>> Also svn merge is very messy and
>> tends to little properties all over the codebase that get very annoying.
>
> IIRC, Manu mentioned that this was a bug in the early 1.6.x versions,
> which seems to be fixed in 1.6.2.

Unfortunately, SVN keeps modifying [from my point of view fully
useless] mergeinfo properties after a partial merge occured (i.e. a
subtree from the source changeset). It rarely happens though.

I've started using 1.6.3, I let you know if this "issue" is fixed
(which is considered as a feature IIUC ;-))

--
Manu

[Christian Boos]

Emmanuel Blot wrote:
>>> Also svn merge is very messy and
>>> tends to little properties all over the codebase that get very annoying.
>>>
>> IIRC, Manu mentioned that this was a bug in the early 1.6.x versions,
>> which seems to be fixed in 1.6.2.
>>
>
> Unfortunately, SVN keeps modifying [from my point of view fully
> useless] mergeinfo properties after a partial merge occured (i.e. a
> subtree from the source changeset). It rarely happens though.
>

Well, and if/when it happens, we can clean it up manually. IIRC, we also
had to tweak the svnmerge-* properties manually a few times in the past
(http://trac.edgewall.org/search?q=svnmerge-&changeset=on).

-- Christian

[Emmanuel Blot]

> Well, and if/when it happens, we can clean it up manually. IIRC, we also
> had to tweak the svnmerge-* properties manually a few times in the past
> (http://trac.edgewall.org/search?q=svnmerge-&changeset=on).

Yeah, I sometimes do this kind of sanitizing on our server (which is
about to reach a grand total of 1500 branches ;-) - although ~50 still
exist at the moment)

[Christian Boos]

Btw, more testing feedback on #7715 (with its latest patch applied (1))
would be highly appreciated: with so many branches, there *must* be some
problematic ones left ;-)

-- Christian

(1) -
http://trac.edgewall.org/attachment/ticket/7715/t7715-fix-eligible-start-r8299.2.patch

[Emmanuel Blot]

> Btw, more testing feedback on #7715 (with its latest patch applied (1))
> would be highly appreciated: with so many branches, there *must* be some
> problematic ones left ;-)

Yeah, still in my TODO list .... (as soon as I get some spare time
after the 10 hours a day of "regular" work ;-))