> -----Original Message-----
> From: Ben Reser [mailto:b...@reser.org]
> Sent: vrijdag 24 januari 2014 18:21
> To: Subversion Development
> Subject: 1.9 issues
>
> As we approach a 1.9 release (not sure what our time frame for release is
but
> I
> think we were expecting roughly a year in Berlin last year) I think there
are
> several issues that need to be discussed and final decisions made. I
don't see
> any of this as a blocker to 1.9.0-alpha1, but they also provide us
questions
> that we may want some help from our users in answering. This are the
> things
> that come to mind, I may have forgotten some so please add to the list if
you
> have things.
>
> 1) svnauth vs svn auth: Right now it's a separate command. I believe this
> functionality is a client function. It really shouldn't be relegated to a
> separate program. Additionally, the separate command is one letter off
from
> the svnauthz program that we already have. Since this is functionality
that is
> entirely client specific and is intended to be used with the command line
> client, I'd argue we should move it into the client as a subcommand. This
is
> going to take some work since svnauth has subcommands already.
>
> The only advantage of the separate program is that it makes it easier to
add
> into the distribution of an older copy of Subversion. But I think we've
added
> new functionality to the libraries to support this, so I don't think it'd
be
> easy to do that anyway.
>
> 2) libsvn_client_mtcc_*: Should these exist at all or be moved to another
> library? This conversation died out.
Responded in a different mail.
And in the old thread...
I don't think that not hearing any interest on this list, makes something
not interesting to implement/release. There is a lot of interest for this
feature in the SharpSvn community, which isn't that active on this list...
as in general they are not interested in implementing low layer code; while
their use cases don't match the 'svn' client either.
>
> 3) Merge tool UI from the conflict resolver. Trunk currently changes 'm'
into
> running the external merge tool first if it exists. But this eliminates
the
> ability to run the internal merge tool directly if you have an external
tool
> configured. I vetoed the backport to 1.8.x, but I don't believe the UI
> concerns I raised have been settled.
I would like to add.
4) Should we expose editor v2?
Personally, I think that (given that nothing has changed to verify the
implementation) we should hide it as private api, just like we did for 1.8.
There are still quite a few known issues in the implementation and I don't
think we should make it an supported ra API until we have at least one
verified RA implementation.
(One of the known issues is that it sometimes uses WORKING and BASE as
referring to the same nodes... Which might work when testing, but certainly
won't work with single replacement or multilayer/replacements and/or moves)
5) What should happen with the new tunnel svn_ra layer? Is it complete?
It looks nice, but in its current state doesn't allow linking a library like
libssh2 on Windows, because there are no callbacks or a proper stream... but
just a pipe.
It probably works for some 'internal implementation' somewhere, but I don't
see a good reason to release it as part of a svn_client_ctx_t change without
a way to hook in libraries.
Higher level libraries (JavaHL, SharpSvn) would love a way to plug in
existing SSH frameworks with hooks for authentication prompts, which doesn't
work right now.
With a pipe you need multiple threads, but the primary thread is not
available for callbacks... and might even continue in certain pipe states
during callbacks of these libraries.
The current implementation looks targeted to specific unix / internal
scenarios.
6) Client side move handling
What is the current status?
I know 'svn update' can still update some nodes that aren't under a working
copy lock; potentially breaking a working copy or independent operations
under their own lock. And quite a few tests fail if I use simple ways to fix
this.
(This is a regression against <= 1.7, but not against 1.8... which still has
this faulty behavior)
7) Server side move handling
Any status updates?
Quite a few apis were revved to expose moves via log, etc., but I didn't see
any completed work on recording them?
Bert
