John Peacock wrote:
> I have no special interest in your tool, which is way too "this is the
> way *we* do things" specific for my taste. You want to add all sorts
> of syntactic sugar which makes your chosen tool easier for *your*
> developers to handle. In my opinion, and that very carries little
> weight in this project as I am only a peripheral developer, this tool
> is far too dedicated to one particular (and I would even say very
> narrow) methodology to belong in the Subversion distro. YMMV.
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'll assume that I am in a working copy that is anchored in the
> project root folder, e.g. //project, so we don't have to worry about
> paths, and run commands which will do what I think you mean.
I understand you are doing this for the sake of simplicity in the example,
but this example is ficticious. It absolutely uncommon and unlikley for
normal developers to have checkouts of the whole project tree, including
*all* the branches, *all* the tags, and all the vendor branches. Thus, in
your example, you're saving precious typing for URLs. Let me remember that
not having to type long URL and remember where vendor projects are stored is
another reason for which I think a specific tool is needed.
>> Now, how can I get back to version 1.1?
>
> $ svk smerge -c ./tags/libcomplex-1.1 ./local/trunk
>
> #if no conflicts
>
> $ svk smerge ./tags/libcomplex-1.1 ./local/trunk
OK, thanks for the explanation. It looks like SVK does everything I need,
minus the automatic management of vendor directory (so that I name vendor
packages by name + version and not by full URL). I still believe there is
value in abstracting from these details, plus I don't plan on using SVK at
the moment.
--
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 18:27:59 2006