> > This output isn't as pretty as the Perforce-like syntax I suggested in
> > the original thread, but it is definitely more explicit. UI
> > suggestions welcome.
>
> FWIW, it is ideas like this one that makes me almost convinced adding
> an explicit subcommand today in 1.5 is the right approach.
Putting an API in place and then writing a separate script to use that
API *just* because we would otherwise be forced to maintain it forever
seems like putting the horse behind the wagon.
Though the line of reasoning is technically correct the picture we're
painting here looks rather strange when looking at it from a users'
perspective: we won't give them certain functionality on the off
chance that it may need to be removed, so we instantiate a script
which - after a certain period of time - will be removed...
I'd be for adding a command to the CLI too, marking it as
experimental. The interface in the C API will be definite and won't be
removed from the API, however the CLI command may change in the
future.
> We ought
> to let the basic functionality get out in the wild and see what comes
> back. David's idea of a feature that tackles this an holistic manner
> like he has proposed might be the better solution. An explicit
> subcommand might be the better solution too. Let's get this out there
> and see.
>
> It'd be nice if there was a function in the library to remove
> something so someone could implement svn viewspec using Python, or
> some other language, and 1.5. Just as svnmerge.py helped define the
> merge tracking feature, something similar could work here.
Why is a python script better than adding it as /experimental/ to the
CLI? I think we may need to amend the versioning policy to do that
though.
Why I think this is acceptable: the CLI isn't a C API...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 7 17:10:08 2007