Hi,
I have written a python (pysvn) script for myself to detect unmerged revs.
Maybe its somehow helpful to you.
I use it like this:
python svn_check_merges branches/<name> /trunk
---------------------------
#!/usr/bin/env python
# -*- python -*- coding: iso-8859-1 -*-
# $Id$
"""
Check if we have all revisison merged in given svn tree, and notifying
the the users, who have still some things to do.
call with:
svn_check_args <svnfrom> <svnto>
where svnfrom and svnto are relative pathes to svnroot
(c) Jan Stürtz js_at_contact.de
"""
import optparse
import pysvn
import sys
import time
SVNROOT = "http://svn.acme.org/svn/src"
def get_mergedrevs(mergedfrom, path):
"""get svn:merginfo Property for a certain path,
and get all revs from there as a set"""
svnwc = pysvn.Client()
props = svnwc.propget("svn:mergeinfo", path)
# Mergeinfo is only one key/val pair, convert to a usable dict
mergeinfo = dict([(tuple(pathitem.split(":")))
for pathitem in props[path].split("\n")])
result = []
if mergedfrom.startswith(SVNROOT):
mergedfrom = mergedfrom[len(SVNROOT):]
for key, val in mergeinfo.items():
if key == mergedfrom:
revs = [(rev.strip().rstrip("*")) for rev in val.split(",")]
for rev in revs:
if rev.find("-") < 0:
result.append(int(rev))
else:
revs = [int(r) for r in rev.split("-")]
# increase by one due to logic of range
revs[1] += 1
result.extend(range(*(tuple(revs))))
break
return set(result)
def get_branchrevs(branch):
"""get all revs from the branch"""
svnwc = pysvn.Client()
logs = svnwc.log(branch)
result = dict([(log.revision.number, log) for log in logs])
return result
def log2str(log):
msg = ""
author = ""
if "message" in log and log.message:
msg = log.message[0:log.message.find("\n")]
if "author" in log and log.author:
author = log.author
return ("%(rev)6s | "
"%(date)10s | "
"%(author)-6s | "
"%(msg)s" %
{"rev": log.revision.number,
"date": time.strftime("%d.%m.%Y", time.localtime(log.date)),
"msg": msg,
"author": author})
def _main():
parser = optparse.OptionParser(usage=__doc__)
parser.add_option(
"--svnroot", default=SVNROOT,
help="Use a different svnroot (default: %s)" % SVNROOT)
(options, args) = parser.parse_args()
if len(args) >= 2:
svnfrom = SVNROOT + args[0]
svnto = SVNROOT + args[1]
else:
parser.error("Missing arguments")
mergedrevs = get_mergedrevs(svnfrom, svnto)
branchrevs = get_branchrevs(svnfrom)
missingrevs = list(set(branchrevs.keys()).difference(mergedrevs))
missingrevs.sort()
per_author = {}
for rev in missingrevs:
log = branchrevs[rev]
print log2str(log).encode(sys.getdefaultencoding(), "replace")
if "author" in log:
if log.author in per_author:
per_author[log.author].append(log)
else:
per_author[log.author] = [log]
if missingrevs:
print "Nonmerged revisions: %d" % len(missingrevs)
if __name__ == "__main__":
_main()
- Jan
Mit freundlichen Grüßen
Jan Stürtz
Software Architect
--
CONTACT Software GmbH Tel.: +49 (421) 201 53-0
Wiener Straße 1-3 Fax: +49 (421) 201 53-41
28359 Bremen - Germany http://www.contact.de/
Sitz der Gesellschaft: Bremen
Geschäftsführer: Karl Heinz Zachries, Ralf Holtgrefe
Eingetragen im Handelsregister des Amtsgerichts Bremen unter HRB 13215
Am 20.06.2011 00:23, schrieb B Smith-Mannschott:
> I've got a trunk and a maintenance branch. I periodically merge
> changes from the maintenance branch to trunk. Merge tracking is a
> help here.
>
> Commits on the maintenance branch begin with an ID identifying the
> issue, backlog item or user story. When I merge changes to trunk, I'd
> like to merge those belonging to the same ID together, but I don't
> want to mix different IDs in the same merge.
>
> To do this, I explicitly name the revisions I want to merge on the command line.
>
> Now, how do I get Subversion to tell me which revisions of <branch>
> have not been merged to <trunk>?
>
> What I've been doing is either (1) firing up TortoiseSVN, which shows
> already merged revisions in grey when you start a log viewer from the
> merge dialog box or (2) actually doing the merge and then meditating
> over the diff of the svn:merge-info property before reverting the
> merge again and doing it properly.
>
> Both of these approaches are awkward in the extreme. Surely I'm
> overlooking something obvious.
>
> // Ben
Received on 2011-07-01 15:24:14 CEST