Trac repos - 'svnmerge.py' vs 'svn merge' (1.5)
osimons
It's been a while since my last commit, and in the meantime something
seems to have changed. I noticed we're now on Subversion 1.5 (good
thing), but I'm mighty confused about merging my revision 8214 to
trunk from 0.11-stable.
Both "svnmerge.py merge -r 8214" and "svn merge -c 8214 <0.11-stable-
url>" seems to give me more than I asked for, including modifying
svn:mergeinfo property not related to files I've touched
(Makefile.cfg.sample). Doing "svn revert Makefile.cfg.sample" cleans
the property again, making the commit-to-be look as I expect (as in:
as it used to look).
However, the fact that we now seem to use both merge tools just makes
me confused. Have any working practice changed? What am I expected to
do when merging - and using what tool?
:::simon
https://www.coderesort.com
Remy Blank
> Both "svnmerge.py merge -r 8214" and "svn merge -c 8214 <0.11-stable-
> url>" seems to give me more than I asked for, including modifying
> svn:mergeinfo property not related to files I've touched
> (Makefile.cfg.sample). Doing "svn revert Makefile.cfg.sample" cleans
> the property again, making the commit-to-be look as I expect (as in:
> as it used to look).
Christian and I talked about it earlier today, and there seems to be
something weird about this particular file, somehow introduced in
[8206]. It may be a bug in Subversion, or a leftover from a bad merge.
> However, the fact that we now seem to use both merge tools just makes
> me confused. Have any working practice changed? What am I expected to
> do when merging - and using what tool?
AFAIK, we're still using svnmerge.py for merging between 0.11-stable and
trunk. Christian has been using "svn merge" for merging from
rework-testing and to multirepos, and this has created the svn:mergeinfo
properties. However, I don't think he's actually using that property,
but keeping track by hand.
So I'd suggest continuing to use svnmerge.py as usual, with the revert
on Makefile.cfg.sample.
-- Remy
osimons
On May 21, 10:14 pm, Remy Blank <remy.bl...@pobox.com> wrote:
> So I'd suggest continuing to use svnmerge.py as usual, with the revert
> on Makefile.cfg.sample.
>
I do wonder if "svn propdel svn:mergeinfo Makefile.cfg.sample" would
do us good... See any problems with that?
:::simon
Remy Blank
> I do wonder if "svn propdel svn:mergeinfo Makefile.cfg.sample" would
> do us good... See any problems with that?
I was thinking the same thing, but I'd like to have Christian comment on
that, as he's the one using "svn merge".
-- Remy
Greg Troxel
osimons <odds...@gmail.com> writes:
> I do wonder if "svn propdel svn:mergeinfo Makefile.cfg.sample" would
> do us good... See any problems with that?
I am using svn 1.5.5 and 1.5.6 with merge tracking. My rule is that
merges may only be done at module roots. This results in no mergeinfo
other than at top level. You may have stray mergeinfo because svn copy
used to create it (but no longer does). Once subtree mergeinfo exists
then any merge will update it, because the node with subtree mergeinfo
no longer inherits from the parent's mergeinfo.
osimons
http://jan.baresovi.cz/dr/en/subversion-mergeinfo
Looking at the property contents, it does look like it is a result of
a reverse merge on own path - and not something intended to be
tracked. The post above also seems to mention the need may arise for
cleaning svn:mergeinfo properties on files and folders further down in
the tree...
+1 on propdel...
:::simon
Remy Blank
> Very useful. Some further digging and I got this "in-a-nutshell" post:
> http://jan.baresovi.cz/dr/en/subversion-mergeinfo
Heh, pretty complicated stuff...
> +1 on propdel...
Sounds reasonable. Go for it!
-- Remy
Christian Boos
> osimons wrote:
>
>> Very useful. Some further digging and I got this "in-a-nutshell" post:
>> http://jan.baresovi.cz/dr/en/subversion-mergeinfo
>>
>
> Heh, pretty complicated stuff...
>
>
Thanks for the link. Hopefully the svn book has a section on that as well.
>> +1 on propdel...
>>
>
> Sounds reasonable. Go for it!
>
Sure, this was a spurious side-effect, and I was puzzled as well as to
why we got svn:merginfo property on that file.
More generally, I think that using svnmerge.py for merging changes from
0.11-stable to trunk is still appropriate, until we eventually gain more
confidence in the new mergeinfo command. We were anyway not using
svnmerge.py for merges in other cases (the occasional trunk ->
0.11-stable backport, sandbox/x -> trunk, trunk -> sandbox/x) and now
when we use svn merge there, the svn:mergeinfo property gets added. So
maybe we should see if we could take benefit from that... (see also the
related posts from today on trac-users).
-- Christian
Emmanuel Blot
I've (we've) been intensively using this feature since early 1.5.0 SVN
release (not w/ edgewall.org).
SVN used to suffer from several major bugs with svn:mergeinfo
management: any SVN tool before 1.5.5 used to create invalid
svn:mergeinfo properties. 1.5.3 being the worst of all, making the
repository nearly unusable.
1.6.0 also shown a regression on this topic. Fixed in 1.6.1, and 1.6.2
seems Ok AFAICT.
The problem is that once *one* file is assigned a svn:mergeinfo
property, the property last forever, and is replicated to/from any
branch that contains the file. If you do partial merge (any operation
of merging a whole changeset from/to a whole tree), svn:mergeinfo
properties are assigned to subdirectory / files.
The common scenario is that you create a branch from a source branch
that contains one or more files tagged with a svn:mergeinfo property.
Once you merge back the branch to the original source branch (svn
merge --reintegrate), the svn:mergeinfo property of this file is
updated, even if you have not touched this file in your development
branch. It looks like a viral behavior, as svn:mergeinfo property set
keeps growing in a repository, and is never shrunk down.
I've even ended up writing a script to remove the svn:mergeinfo
properties that used to pollute our branch, till SVN 1.5.5, as those
properties were sometimes invalid.
Anyway, since 1.5.5 (and 1.6.1), SVN seems to manage the svn:mergeinfo
properties the right way. However it keeps polluting the repository
view in Trac as Trac keeps rendering this property.
*I do think Trac should not try to render this property, at least in
the default view*. The best option I see is that Trac should show if a
svn:property exists, but should hide the actual property value (which
ends up to be very, very long, about 30 lines in our own trunk...),
and offer a link to render the property value, i.e. the mergeinfo
sources.
I've never been a fan of the svnmerge.py script, and hardly used it.
However we are now using svn merge --reintegrate and svn merge -r x:y
several times a day with no particular issue, and it works as
expected.
There's one terrible lack though: the server should be able to detect
the svn client version to reject invalid clients, such as the awful
1.5.3 series: if *one* svn invalid client sends incorrect
svn:mergeinfo properties to the server, it leaves the repository
within an unmanageable state: the admin needs to clean up those
properties as soon as possible, or valid clients start to branch and
bring the invalid properties within their own branches, then merge it
back to the source branch: it may takes weeks to finally remove
invalid svn:mergeinfo properties once they are dispatched in other
branches then merged back. And sometimes, there are no other choice
than deleting the property itself, which may jeopardize future merge
operations....
Cheers,
Manu
Christian Boos
Thanks for sharing your experience with us!
Emmanuel Blot wrote:
> About my svn merge experience:
>
> I've (we've) been intensively using this feature since early 1.5.0 SVN
> release (not w/ edgewall.org).
>
> SVN used to suffer from several major bugs with svn:mergeinfo
> management: any SVN tool before 1.5.5 used to create invalid
> svn:mergeinfo properties. 1.5.3 being the worst of all, making the
> repository nearly unusable.
> 1.6.0 also shown a regression on this topic. Fixed in 1.6.1, and 1.6.2
> seems Ok AFAICT.
>
> The problem is that once *one* file is assigned a svn:mergeinfo
> property, the property last forever, and is replicated to/from any
> branch that contains the file. If you do partial merge (any operation
> of merging a whole changeset from/to a whole tree), svn:mergeinfo
> properties are assigned to subdirectory / files.
ok
>
> The common scenario is that you create a branch from a source branch
> that contains one or more files tagged with a svn:mergeinfo property.
> Once you merge back the branch to the original source branch (svn
> merge --reintegrate), the svn:mergeinfo property of this file is
> updated, even if you have not touched this file in your development
> branch. It looks like a viral behavior, as svn:mergeinfo property set
> keeps growing in a repository, and is never shrunk down.
scary ...
>
> I've even ended up writing a script to remove the svn:mergeinfo
> properties that used to pollute our branch, till SVN 1.5.5, as those
> properties were sometimes invalid.
>
> Anyway, since 1.5.5 (and 1.6.1), SVN seems to manage the svn:mergeinfo
> properties the right way. However it keeps polluting the repository
> view in Trac as Trac keeps rendering this property.
>
> *I do think Trac should not try to render this property, at least in
> the default view*. The best option I see is that Trac should show if a
> svn:property exists, but should hide the actual property value (which
> ends up to be very, very long, about 30 lines in our own trunk...),
> and offer a link to render the property value, i.e. the mergeinfo
> sources.
I see your point. However I wonder if we couldn't come up with a useful
and compact way to show this information. Could be as simple as:
svn:mergeinfo:
- sandbox/rework-merging merged eligible
- branches/0.11-stable merged eligible
With merged/eligible links to the revision log with the corresponding
ranges (the tooltip also showing the revision ranges).
That list could eventually be pruned from the paths which are no longer
existing (or do you really have 30 active branches?)
> I've never been a fan of the svnmerge.py script, and hardly used it.
Well, at least svnmerge did its job and was never a source of headaches ;-)
Actually, svnmerge.py will call 'svn merge', so when using a recent svn
you end up with some svn:mergeinfo in any case (e.g.
http://trac.edgewall.org/changeset/8222).
> However we are now using svn merge --reintegrate and svn merge -r x:y
> several times a day with no particular issue, and it works as
> expected.
That's reassuring - it gives me more incentive to invest some time in this.
>
> There's one terrible lack though: the server should be able to detect
> the svn client version to reject invalid clients, such as the awful
> 1.5.3 series: if *one* svn invalid client sends incorrect
> svn:mergeinfo properties to the server, it leaves the repository
> within an unmanageable state: the admin needs to clean up those
> properties as soon as possible, or valid clients start to branch and
> bring the invalid properties within their own branches, then merge it
> back to the source branch: it may takes weeks to finally remove
> invalid svn:mergeinfo properties once they are dispatched in other
> branches then merged back. And sometimes, there are no other choice
> than deleting the property itself, which may jeopardize future merge
> operations....
Understood. But what is the relevance of the version of the Subversion
/server/, in this picture?
svn.edgewall.org runs Subversion 1.5.1. Is that a problem?
-- Christian
Emmanuel Blot
> Thanks for sharing your experience with us!
I found only a little information on merging (I mean, real experiences
about SVN merging), so I thought it could give some hints.
> I see your point. However I wonder if we couldn't come up with a useful
> and compact way to show this information. Could be as simple as:
>
> svn:mergeinfo:
> - sandbox/rework-merging merged eligible
> - branches/0.11-stable merged eligible
I'm not sure about the meaning about the eligible keyword here?
I use --show-revs eligible to get information about what can be
merged, but what would be the meaning once the merge operation has
been completed? Is it to differenciate from a user-selected merge
source?
> That list could eventually be pruned from the paths which are no longer
> existing
I think that would make sense if "no longer exist" is not an absolute
time, but a time relative to the merge operation itself, i.e. the
source branches that still exist at the time of the merge operation
that created the changeset. I'm not sure this shortcut could be
applied for all SVN projects though.
There still should be an option to see the actual source branches
(even once they have been deleted).
> (or do you really have 30 active branches?)
Let's see: 24 product more or less active branches, 44 developer
active branches in our main repository (we have 10 of them)
svn pg svn:mergeinfo on /trunk currently returns 373 lines, knowing
that there would be over 1000 of them if I hadn't had to remove
svn:mergeinfo properties in the early 1.5.x times ;-)
> Understood. But what is the relevance of the version of the Subversion
> /server/, in this picture?
> svn.edgewall.org runs Subversion 1.5.1. Is that a problem?
It has never been an issue for us at least: we've used 1.5.1 (Debian)
for over 1 year, then I've upgraded the server to 1.5.6. I'm waiting
to upgrade the server to 1.6.2, as I'd like to benefit from some of
the new features such as
http://subversion.tigris.org/svn_1.6_releasenotes.html#filesystem-improvements
However, as I've been disappointed more than once with SVN 1.5.x
clients, I've been refraining from upgrading the server up to now: I
want to be sure it is stable enough before upgrading.
Let me know if you need some beta tester for this feature: I could
create a "ghost" Trac environment pointing onto the actual SVN
repository to perform some rendering tests.
Cheers,
Manu
Christian Boos
> Hi,
>
>
>> Thanks for sharing your experience with us!
>>
>
> I found only a little information on merging (I mean, real experiences
> about SVN merging), so I thought it could give some hints.
>
>
>> I see your point. However I wonder if we couldn't come up with a useful
>> and compact way to show this information. Could be as simple as:
>>
>> svn:mergeinfo:
>> - sandbox/rework-merging merged eligible
>> - branches/0.11-stable merged eligible
>>
>
> I'm not sure about the meaning about the eligible keyword here?
> I use --show-revs eligible to get information about what can be
> merged, but what would be the meaning once the merge operation has
> been completed? Is it to differenciate from a user-selected merge
> source?
>
No, it's just what `svn mergeinfo --show-revs eligible` would show... I
was thinking about the repository browser view, here. I suppose you were
thinking about the changeset view. There, we could simply show what has
been merged, in a way very similar to svn diff, e.g.
trunk> svn diff -c8225
...
Modified: svn:mergeinfo
Merged /branches/0.11-stable:r8215-8216
>> That list could eventually be pruned from the paths which are no longer
>> existing
>>
>
> I think that would make sense if "no longer exist" is not an absolute
> time, but a time relative to the merge operation itself, i.e. the
> source branches that still exist at the time of the merge operation
> that created the changeset. I'm not sure this shortcut could be
> applied for all SVN projects though.
> There still should be an option to see the actual source branches
> (even once they have been deleted).
>
>
>> (or do you really have 30 active branches?)
>>
>
> Let's see: 24 product more or less active branches, 44 developer
> active branches in our main repository (we have 10 of them)
>
> svn pg svn:mergeinfo on /trunk currently returns 373 lines, knowing
> that there would be over 1000 of them if I hadn't had to remove
> svn:mergeinfo properties in the early 1.5.x times ;-)
>
Ok, I see... So we really need to imagine something that can scale.
>
>> Understood. But what is the relevance of the version of the Subversion
>> /server/, in this picture?
>> svn.edgewall.org runs Subversion 1.5.1. Is that a problem?
>>
>
> It has never been an issue for us at least: we've used 1.5.1 (Debian)
> for over 1 year, then I've upgraded the server to 1.5.6. I'm waiting
> to upgrade the server to 1.6.2, as I'd like to benefit from some of
> the new features such as
> http://subversion.tigris.org/svn_1.6_releasenotes.html#filesystem-improvements
>
>
Good to know.
> However, as I've been disappointed more than once with SVN 1.5.x
> clients, I've been refraining from upgrading the server up to now: I
> want to be sure it is stable enough before upgrading.
>
> Let me know if you need some beta tester for this feature: I could
> create a "ghost" Trac environment pointing onto the actual SVN
> repository to perform some rendering tests.
>
>
Ok, fine!
-- Christian
Emmanuel Blot
> was thinking about the repository browser view, here. I suppose you were
> thinking about the changeset view. There, we could simply show what has
> been merged, in a way very similar to svn diff, e.g.
> trunk> svn diff -c8225
> ...
> Modified: svn:mergeinfo
> Merged /branches/0.11-stable:r8215-8216
Not sure to understand
svn mergeinfo --show-revs eligible shows what could be merged
svn mergeinfo --show-revs merged shows what have been actually merged
I'm not sure what you'd want to show with 'eligible'?
What would be the source branch(es) in this case?
Cheers,
Manu
Christian Boos
Look at my example again.
Imagine you would see the following, when browsing
http://trac.edgewall.org/browser/trunk
svn:mergeinfo:
- sandbox/rework-merging merged eligible
- branches/0.11-stable merged eligible
i.e. for each source branch, you'd see what was already merged and
what's still available for merge.
In this example, the 'eligible' link for branches/0.11-stable would link
to http://trac.edgewall.org/log/?revs=8184,8198,8211,8217-8218 (as of
r8227).
Currently the 'eligible' info for sandbox/rework-merging is ... r8000,
which is the revision corresponding to the branch creation. But that's
probably due to an older svn 1.5.x being used at that time ;-)
Knowing what is 'eligible' from a given branch is a quite important
information to my eyes, as with 'svn merge' you have to explicitly tell
what revisions you want to merge (except for the --reintegrate special
case).
-- Christian
Greg Troxel
Christian Boos <cb...@neuf.fr> writes:
> Knowing what is 'eligible' from a given branch is a quite important
> information to my eyes, as with 'svn merge' you have to explicitly tell
> what revisions you want to merge (except for the --reintegrate special
> case).
You don't have to specify if you want to take all the eligible revisions.
We have feature branches, and do
WC/foo $ svn merge https://repobox/svn/project/foo/trunk
(via script to get the details right) to take all trunk revisions that
have not been merged to the branch and merge them. Sometimes this just
updates ergeinfo, if there are revisions in the repo that don't affect
that module.
I didn't know about svn log -g, but it would be nice if the source
browser showed that info.
Emmanuel Blot
> what's still available for merge.
Ok I think I get it.
This information is useful, however eligible can only be shown
* if you have started to merge some changeset from a source branch, and
* if you have not merged all the changeset from the source branch
In other words, it cannot show the eligible candidates from branches
you've never merged back from.
IMHO, the term "eligible" here can be quite confusing: you cannot
assume the list of valid source URLs.
> In this example, the 'eligible' link for branches/0.11-stable would link
> to http://trac.edgewall.org/log/?revs=8184,8198,8211,8217-8218 (as of
> r8227).
However, imagine I've created a branch from /trunk@8200, this branch
would be eligible but not appear as eligible till I start merging it
back to the trunk.
> Knowing what is 'eligible' from a given branch is a quite important
> information to my eyes, as with 'svn merge' you have to explicitly tell
> what revisions you want to merge (except for the --reintegrate special
> case).
... which lead to another important point: 95% of our merge operations
are made out of "svn merge --reintegrate".
Maybe a special case, but something heavily used in our development
cycle. All the candidates for merge --reintegrate would not appear as
"eligible" here.
Cheers,
Manu
Greg Troxel
... which lead to another important point: 95% of our merge operations
are made out of "svn merge --reintegrate".
Maybe a special case, but something heavily used in our development
cycle. All the candidates for merge --reintegrate would not appear as
"eligible" here.
That seems odd - to use --reintegrate you have to first merge the parent
to the feature branch. So I'd expect.
create branch
multiple copies each of
hack on branch
merge trunk to branch
reintegrate merge
delete branch
In our world, 95% of merges are parent to feature branch.
Christian Boos
>> i.e. for each source branch, you'd see what was already merged and
>> what's still available for merge.
>>
>
> Ok I think I get it.
>
Not sure we're on the same line yet, as I was talking of displaying in a
nice way the content of the *svn:mergeinfo* property.
> This information is useful, however eligible can only be shown
> * if you have started to merge some changeset from a source branch, and
>
so obviously, if the branch is listed in the svn:mergeinfo, it's because
a merge has already been done, and therefore there's at least some
"merged" info to show, and possibly "eligible" as well...
> * if you have not merged all the changeset from the source branch
>
... unless there's nothing more to merge, in which case we could always
show (nothing to merge) instead of the "eligible" link.
> In other words, it cannot show the eligible candidates from branches
> you've never merged back from.
> IMHO, the term "eligible" here can be quite confusing: you cannot
> assume the list of valid source URLs.
>
Sure, but this is not what I wanted to do.
>> In this example, the 'eligible' link for branches/0.11-stable would link
>> to http://trac.edgewall.org/log/?revs=8184,8198,8211,8217-8218 (as of
>> r8227).
>>
>
> However, imagine I've created a branch from /trunk@8200, this branch
> would be eligible but not appear as eligible till I start merging it
> back to the trunk.
>
>
>> Knowing what is 'eligible' from a given branch is a quite important
>> information to my eyes, as with 'svn merge' you have to explicitly tell
>> what revisions you want to merge (except for the --reintegrate special
>> case).
>>
>
> ... which lead to another important point: 95% of our merge operations
> are made out of "svn merge --reintegrate".
> Maybe a special case, but something heavily used in our development
> cycle. All the candidates for merge --reintegrate would not appear as
> "eligible" here.
>
Right, I have to give more testing to this use case.
-- Christian