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

Re: Re: [PATCH] Fix issue #1976: Set arbitrary revision properties (revprops) during commit.

From: Peter Lundblad <plundblad_at_google.com>
Date: 2007-02-20 16:19:26 CET

Gerco Ballintijn writes:
> Yes, as I realize now there are three ways to go: (1) Provide the revision
> properties as part of the get_commit_editor() call, what I did in my patch;
> (2) Provide the revision properties through a new change_file_prop() "method"
> in the svn_delta_editor_t struct; or (3) Provide the revision properties as
> part of the close_edit() method of the svn_delta_editor_t struct. Method (1)
> and (3) seem to have the least impact on the existing code, but method (2)
> is the cleanest and most generic. (Method (2) and (3) both allow the revision
> properties to be provided at the end).
>

Unfortunately, the editor is not documented to be extensible, so
approaches 2 and 3 will require revising that struct, which will be a lot
 of work. If someone wants to take that (whictch we will need to do at
some point for other things), that'd be great, but I'm not sure I think
this feature need to block on that, especially since it can be useful
without the ideal genericity.
>
> >>
> >> A separate issue was (is) whether to ignore, to filter, or to flag the
> >> standard revision properties as errors when passed in the table.
> >>
> >
> > I think it would make sense to disallow any changes to the svn:
> > properties, since they're already set through other processes (and you
> > wouldn't want, for example, to have to work out whether someone could
> > override svn:author).
> >
>
> But would such a prohibition be for the command-line client *only* or
> for all (relevant) public APIs?
>
To make sense, this has to be prohibited on the server side.

>
> >
> > I also wondered whether we should be calling the pre- and post-
> > revprop-change hooks, or whether we just leave it to the pre-commit
> > hook.
> >
>
> The notes in the bugtracker seem to suggest that since this new functionality
> is not about changes historic data, but about creating new historic data, no
> call to the revprop-change hooks is needed. This seems to me a reasonable
> stance.
>
I agree. I don't think the change revprop hooks should be called.
The pre-commit hooks can do necessary checking.

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 20 16:20:08 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.