On 4/18/07, Daniel Rall <dlr@collab.net> wrote:
> 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.
The mergeinfo structure would be great! No need for a textual
representation, I just would have to parse those which shouldn't be
necessary if the mergeinfo structure contains the information.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 18 07:21:28 2007