subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Subversion Wiki] Update of "MergeInfoDisplay" by JulianFoad
Date Tue, 04 Oct 2011 17:54:06 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "MergeInfoDisplay" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/MergeInfoDisplay

New page:
== Aim ==
Make it much harder to merge the “Wrong Way” by accident.

Identify  the typical merging tasks, which may vary depending on the requirements  of the
user’s team.  Make the typical merging tasks easy to perform;  look at TortoiseSVN and other
existing GUIs for examples. Clearly  distinguish tasks that have different meanings but may
currently have  similar or identical syntax, to reduce the risk of a user performing a  merge
that produces the desired output now but will adversely affect  future merges.  Make it harder
to accidentally specify merges that are  unusual and not well supported.

Implement  these measures by building onto Subversion’s existing library API,  command-line
UI, client-server interface and/or any other suitable  level.  If this requires knowledge
of the user’s branching model and  rules, provide a simple way to configure this and provide
one or more  typical configurations.

A  pre-requisite for designing and implementing such guidance is a clear  statement of what
merging scenarios Subversion supports.  See the  document [[https://docs.google.com/document/d/1wUCZOEywizf88BGjQn8RWqZ3reOoQXEsOnMOybK6qpI/edit?hl=en_GB|Supported
Merge Scenarios]].

== Reporting -- What “svn merge” Should Say ==
“svn  merge” should first of all give a summary of what it is about to do,  using words
that make sense to the user.  Consider stopping to ask for  confirmation (unless --no-interactive).
 Some of the output should be a  summary of what is calculated as needing to be merged.  That
is not only  a chance to check the user’s expectation, but in a merge that involves  significant
calculating of source revisions, it is also a chance for the  user to see that Subversion
has been doing something useful up to this  point and is about to move on to the next stage
of actually merging  those revisions.

So for example:

{{{
$ svn co $URL/branches/dev1 wc1
$ cd wc1
$ svn merge --reintegrate ^/branches/feature2
Reintegrating '/branches/feature2' into working copy of '/branches/dev1'
}}}
and then a summary of the current merging status:

{{{
Previous merges from ‘/branches/feature2’ into ‘/branches/dev1’
4 source changes (latest: r144) in 2 merges (latest: r145)
}}}
and any warnings:

{{{
warning: working copy contains modifications (all in ‘docs/’)
}}}
{{{
warning: working copy is not up to date
}}}
{{{
warning: ‘/branches/feature2’ is not up to date with ‘/branches/dev1’:
   2 changes (latest: r166) have not yet been merged.
   Run ‘svn mergeinfo’ for details.
}}}
== Reporting -- What “svn mergeinfo” Should Say ==
In  order for a user to understand what merges they have done and need to  do, it would be
most helpful if Subversion could tell them the current  state of a branch with regard to merges.
 The existing “svn mergeinfo”  command is near useless for such understanding: it just
outputs a list  of revnums without saying what that means in terms of whether the target 
is fully caught up or not; it doesn’t report anything meaningful about  subtree merges and
doesn’t even notice them by default; it doesn’t check  that you specified a sensible source
branch and simply says nothing if  you accidentally specified the target branch. In a WC of
''feature branch'' “B”, which has had catch-ups through trunk@1234 except trunk@1215:
* Mergeinfo summary:

 * $ svn mergeinfo ^/trunk
 * Origin: ^/branches/B@1200 (from ^/trunk@1190)
 * Merged from ^/trunk:
 * Origin-1214, 1216-1234

 * Automatic identification of the ''parent'' branch:

  * $ svn mergeinfo
  * Parent branch is ^/trunk.
  * [... continue as for “svn mergeinfo ^/trunk” …]
 * Failed to identify a parent branch:
  * $ svn mergeinfo
  * svn: No parent branch configured for ^/branches/B
 * When no relationship is configured between this and the specified branch:
  * $ svn mergeinfo ^/branches/B2
  * No declared relationship between ^/branches/B and ^/branches/B2.
  * Merged from ^/branches/B2:
  * 905,970-977

Mergeinfo should be “recursive” by default, reporting any sub-tree differences, where
presently it does not. * How should the output look in the presence of subtree merges?

 * $ svn mergeinfo

=== Mergeinfo Diff (bug) ===
Diff,  when displaying an added mergeinfo property on a sub-tree, should diff  against the
previously inherited mergeinfo, not say that all this new  mergeinfo represents merges that
have just been done.  Similarly for a  deleted prop. Discussed in [[http://svn.haxx.se/dev/archive-2011-09/0201.shtml|this
email thread]].

Mime
View raw message