John Peacock wrote:
>> If you did not read the document, how can you know that the tool is
>> too specific? In my opinion, it allows to do all the common
>> operations needed to handle vendor branches. I would be pleased if
>> you could show me a specific usage case which the tool is not able
>> to cover. In fact, it automates the usage pattern of vendor branches
>> described in the SVN book too.
>
> I did read the document, just not at the level required to consider
> all of the implementation details. You can accuse me of a drive-by
> review, to which I would gladly admit to. I'll try to go through in
> more detail now, but my gut instinct is that you have already chosen
> the means that you want to use to solve your "problem" without having
> spent enough time defining the "problem" you want to solve.
The document contains a section called "requirements". That's what I'm
trying to obtain. Each of the requirement comes from a problem with the
current user interface.
> You are trying to hide the implementation details from the user, which
> very much goes against the grain of the Subversion core.
It does not necessarily mean Subversion did it right. There have been
recurring threads/flames on how to avoid typing those URLs on the command.
Irrespective of what you or I personally feel, there are people who strongly
believe that typing those URLs is totally unnecessary. For once, it totally
violates the "say it once" principle: I said the full URL once at checkout
time, and I never want to repeat it again; give me repo-relative paths on
the command line, thanks. SVK's "//" works very well here. For instance, CVS
was able to do "cvs diff -jMY_BRANCH foo.c". I understand why it's not
possible to do it in Subversion, but the problem is that it's impossible to
do it *even* if you play by all the rules/standard/defaults.
For instance, I have some small tools I have never contributed which I use
to avoid needless fingertypes. "createbranch BRANCHNAME" in a working copy.
"switchto BRANCHNAME" in a working copy. "diffto BRANCHNAME" in a working
copy. Ok, maybe they don't work with every possible layout in the world, but
I use them successfully in different projects and different repositories. I
have still to work in a project where the SVN repository does not follow the
/trunk, /branches, /tags arrangement. I'll keep the tools for me and leave
you to your wasteful fingertyping, but I think this might help to understand
where I'm coming from.
Also, *exactly because* the Subversion core MUST not know anything more than
directories and versioned copies, I believe that this kind of "heuristic"
must be done on external, layered tools. Maybe these tools are not useful
for *everybody* using Subversion, true. But if they meet common usage
patterns, that's enough to justify their existence, in my opinion.
> In
> particular "Implicit URLs" make some huge leaps of faith about the
> repository layout which just isn't true for many sites.
Browsable examples of repositories which would make the configuration file
useless and would force the user to always use URLs? Or, at least, can you
describe with words such repositories?
> You have chosen two common layouts and tried to hide the details in a new
> configuration file. Your proposal is not extensible, however.
This is incorrect. I think I made clear that the configuration file is used
so that people can refer to a vendor branch *only* by using its name. In
case it wasn't clear, it will still be possible to point to the vendor
branch with the full URL, in case you decided to put it in a place different
from all the other vendor branches in the same project.
> You've spent a fair amount of time coming up with the commandline
> invocations,
... which I believe to be a *crucial* point. I want to provide an easy
interface for the users (which include myself).
> but it doesn't seem like much time in considering the
> implementation details. For a simple example, some external library
> use versions ala 1.23 and others user 1.2.3; how are you going to
> determine which is the "latest" vendor branch?
Yes, that is something to be discussed. I believe a simple algorithm will
work in most cases (comparison of tuple(v1.split(".")), I can elaborate
further if you are interested), but note that this is absolutely not a
showstopper. Even if the heuristic is incorrect, it's possible to
explicitally specify the version on the command line. And I could add
something like --version=HEAD/LATEST to mean "the latest one that was
imported into the vendor branch".
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 19 20:21:11 2006