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

Re: merge tracking on the 1.5 branch

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 1 Feb 2008 12:31:02 -0500

On Feb 1, 2008 12:00 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
> > IMO, a 1.5 client should never set svn:mergeinfo when talking to a 1.4
> > repository (note that I said "repository", not server). To accomplish
> > this, we need to grow FS-level capabilities reporting and integrate
> > that into our RA capabilities checks.
> This is an interesting point.
> Up till now, we haven't carefully distinguished between server
> capabilities and repository capabilities. Here are tentative
> classifications of all our current svn_ra capabilities:
> SVN_RA_CAPABILITY_DEPTH ============> really about server
> SVN_RA_CAPABILITY_MERGEINFO ========> really about repository
> SVN_RA_CAPABILITY_LOG_REVPROPS =====> really about server
> SVN_RA_CAPABILITY_PARTIAL_REPLAY ===> really about server
> Since every RA session is anchored on a particular URL -- that is, a
> particular repository -- one way to handle SVN_RA_CAPABILITY_MERGEINFO
> is to have it report negative if the repository in question does not
> support mergeinfo, *even* if the server itself is 1.5 or higher.

My only concern would be whether it hinders our ability to provide an
accurate error message to the user. As I mentioned before, I see a
lot of users being confused that they upgrade a server to 1.5 but
cannot use merge tracking because of the repository. So our message
would need to be different for talking to a pre-1.5 server vs. a 1.5
server with a repository that needs to be upgraded. Of course, one
carefully crafted error message could almost certainly serve both
purposes too.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-01 18:31:13 CET

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.