On Tue, 2004-03-09 at 15:49, Ben Reser wrote:
> We either have to punt this until 2.0 or fudge on our compatability
> guarantees IMHO.
Before I start, a non-technical note: lots of people will continue using
VS7 for a long time after Whidbey comes out, but just how big is the
intersection of {people who won't upgrade their development environment}
with {people who will migrate to a new version control system}?
Moving on, my best understanding of the technical situation is:
* We have this constant SVN_WC_ADM_DIR_NAME. It's used outside
libsvn_wc to:
- Ignore .svn dirents when exporting a working copy
- Prohibit .svn dirents when committing
- Ignore .svn dirents when recursively adding
- Ignore .svn targets in svn_opt_args_to_target_array
(Ironically, "svn import" doesn't seem to use it, even though svn_wc.h
lists import as the reason for its existence.) Obviously, third-party
apps could be using it for unknown purposes.
* We don't pass config hashes to most libsvn_wc functions, so we would
have to add enhanced versions of many functions in order to add a config
option.
As a result of the first bullet point, anything we do in svn 1.x risks
incompatibility with third-party apps which use SVN_WC_ADM_DIR_NAME (to
detect working copies, say). However, such incompatibilities would only
be experienced by people who actually use the feature, and those people
who use it presumably couldn't use Subversion at all without it.
As a result of the second bullet point, it would be much easier for us
to use an environment variable instead of a config variable. (And since
many of us, myself included, favor doing nothing at all, we should
really be looking for the easy hack here, not the elegant solution.) We
don't use environment variables for most configuration, but we do in a
couple of cases (SVN_SSH and SVN_EDITOR), so it wouldn't be totally
unprecedented.
So, here are the options I see:
* Do nothing. This preserves the sanity of our code base, but
prevents some unknown fraction of VS7 users from using Subversion. (One
of the big unknowns in these conversations is what fraction of VS7 users
actually use the VS7 features which use the MSFP extensions which don't
interoperate with svn working copies.) Ten years down the road, this
will look like the best choice, since we won't have complicated our code
base and VS7 will be a historical relic. I'm +1 on this option.
* The dirty hack: Introduce an environment variable to change the .svn
dir and document it as a barely-functional workaround which we reserve
the right to desupport in the far future. Don't try to recognize both
kinds of working copies, don't provide functions to help third-party
apps recognize variant working copies, etc.. If we go this route, I
actually like the idea of letting the environment variable specify any
value (not just _svn), because it makes it less likely that people will
write third-party heuristic code which tries to recognize variant
working copies. I'm -0 on this option.
* The more elegant, invasive hack: Introduce a config file option to
change the admin directory to _svn. Augment most of the libsvn_wc
functions to accept a config hash. Add a libsvn_wc function which
yields the administrative directory name, and advise third-party code to
start using it in favor of SVN_WC_ADM_DIR_NAME. I dislike this option
because it greatly complicates the code base and bends our compatibility
rules. There is a complexity threshold we should not exceed for working
around other people's bugs, and this is way beyond it. I'm -1 on this
option.
The latter two options would be for 1.1.x. 1.0.x is out of the question
(nothing we could do qualifies as a simple bugfix). 2.0 would allow us
to accomplish the third option with a bit less pain, but I hope that by
the time 2.0 comes out, VS7 will already be looking pretty historical.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 9 22:43:43 2004