[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge Tracking Auditing - SoC

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-04-18 01:21:06 CEST

On Tue, 17 Apr 2007, Stefan Küng wrote:

> Hyrum K. Wright wrote:
...
> >So, basically something to the effect of: (the revision numbers below
> >are somewhat bogus.)
> >
> >------------------------------------------------------------------------
> >r24602 | dlr | 2007-04-16 19:02:48 -0500 (Mon, 16 Apr 2007) | 3 lines
> >=== result of merge in r24678 ===
> >
> >* notes/merge-tracking.txt
> > Add issue #2769, and sign up for it.
> >
> >------------------------------------------------------------------------
> >r24601 | dlr | 2007-04-16 18:50:29 -0500 (Mon, 16 Apr 2007) | 3 lines
> >=== result of merge in r24678 ===
> >
> >* notes/merge-tracking.txt
> > Sign Kamesh up for the "all unmerged revisions" task, per his request.
>
> I like that idea. But for me, how the log message output looks is not
> that important. For me, it's more important how that data is passed in
> the API. I suggest something like a map of revisions which got merged.

Stefan, I've been assuming that we'd use a "mergeinfo" structure.
That is, an apr_hash_t * of const char *path -> an apr_array_header_t *
containing svn_merge_range_t *'s. Does this sound good to you?
Alternately, we could pass in the textual representation of the merge
info.

  • application/pgp-signature attachment: stored
Received on Wed Apr 18 01:21:30 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.