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

Re: No no-op changes

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 22 Sep 2014 11:45:01 -0400

On 09/22/2014 11:04 AM, Julian Foad wrote:
> Would you accept that it now makes more sense to make the overall
> system behaviour more consistent by moving towards the majority
> direction (not preserving no-ops)? At least at some layers -- repos
> layer or RA layer?

"At least at some layers", yes, absolutely.

In general, I favor consistency, but the scope of that consistency
matters, especially in a modular system such as Subversion. For
example, I've always appreciated the idea that the Subversion FS layer
was designed with academic DAG-based version control theory in mind (not
mine, of course!), and as such will allow some things to happen that
perhaps we prefer to block from happening at levels of Subversion which
are closer to the end user. Some have argued that this should not be --
that the FS layer should enforce exactly what the client layer does. I
disagree.

More to the topic, I continue to see value in preserving no-op
operations in the FS layer. But at the client end of things, I would
agree that the most users don't care to be bothered by such nuances. So
as it does for others of those behaviors that differ at extreme ends of
the Subversion system, some mitigation needs to take place somewhere in
the middle. And that "somewhere" depends on what you want to permit.
For example, if that mitigation happens at the repos layer, that's fine
for the most part ... but what about the likes of 'svnrdump', which is
trying its darnedest to act like a repos-layer dump/load driver but sits
on the other end of the higher RA layer?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development
Received on 2014-09-22 17:45:41 CEST

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.