Just curious...
I just started reading this whole discussion. Couldn't all of this
checking be added to a pre-commit hook? I already have a hook that
verifies that particular properties are added and are in the correct
format. It would be very simple enhance the hook to forbid svn:*
properties that aren't valid.
On 8/1/05, Dale Worley <dworley@pingtel.com> wrote:
> > From: John Peacock [mailto:jpeacock@rowman.com]
> >
> > Yes, but my objection to locating this code _in the client_ is still
> > there. Say we add this to 1.3 and then for 1.4, a new svn: property
> > gets added (say svn:log-template). Now our compatibility guidelines
> > require that a 1.3 client must be able to communicate with a 1.4 server,
> > but it doesn't have to get all of the new functionality. In this case,
> > any 1.3 client must use --force to set the svn:log-template property.
>
> I missed the message where you first mentioned this...
>
> I see your point, but as long as it's possible for an old client to cope
> transparently with "new" properties *already existing* in the repository,
> that seems to me to be sufficient. I don't see any real objection to having
> to use --force to *add* "new" properties. Of course, this will be a
> nuisance for ongoing work, but the client can be upgraded when it is
> convenient to do so.
>
> So as long as it's clarified that unknown svn: properties will be screened
> only when they are added (and not when they are already present in the
> repository), I think the downward-compatibility to older clients is OK.
>
> Dale
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 2 16:06:02 2005