>> I didn't read your entire post,
> OK, if it's too long to read, here are the problems in a nutshell:
Not really to long, but time is limited and I wasn't sure if it would be
worthwile to read. Maybe a lame excuse, but it's the truth.
Thanks for the nutshell summary.
> 1. Moving subdirectories is readily accepted by TSVN, but when
> committing that change, TSVN will fail.
> According to my experiments, moving a subdirectory is only possible if
> the commit is split in two, a directory deletion (which will work only
> if the commit is "anchored" at the directory being deleted) and
> directory addition.
I can't reproduce that with my setup. What version of TSVN are you
running?
To commit such a change you must issue the commit-command at a directory
in the WC on a level above the operation. It is generally considered a
best practice to make it a habit to commit from the root of you WC.
Can you reproduce this using a simple dumy-repository? For example the
revgraph-test-repos:
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/test/BuildRevisionGr
aphTestRepo.bat
Provide a step-by-step recipe on a know test-repository and I'm sure we
can sort this out.
> 2. There are several actions that can get TSVN into a state that's
> inconsistent with the repository's state. This is... er... unsettling,
> even if the inconsistency seems to be fixable via the Update function.
This is *very* unsettling to say the least. If you find any such cases,
please provide a step-by-step reproduction recipe using the command line
client and post it to the SVN-project. TSVN uses the SVN API for all WC
modifications and repository communication. If you only can reproduce
the problem with TSVN, and not the command line client, (which *should*
not be possible), post the recipe to the TSVN-list.
>> so I'm sorry if I'm jumping to conclusions here...
> Sorry, but I think that's indeed the case.
*grin* Thank you for your honesty. I'll cut the comments a little short
so that the post don't grow out of bounds completely, trying to keep to
the tips I can provide.
> The problem is that even though the SVN manuals do a great job at not
> stating the obvious, they are still too much.
I know that feeling.
> I read the whole thing > cover-to-cover, and re-read those sections
> that I considered relevant for me - yet I'm still not 100% sure that
> I remember every relevant detail.
That's a general problem for complex systems. There is very much to
know. I do certainly not remember every aspect (proven on this list
numerous times) even though I have (re)read the manual a number of
times.
> In other words, if there's a way to get things into the program
> instead of having to read them up, that option should be taken
> if at all possible :-)
We (read Stefan^1) is trying our best with TSVN. But we are still bound
by the decisions made by the SVN project.
> BTW I'm the lead introducing SVN into a project. The programmers
> I'm working with won't accept a RTFM, they simply want the job done,
> and if SVN gets in their way, they will oppose it.
I'm much in the same situation. My solution to that general problem was
writing a small (*cough*) guidelines-document that provides a basic
introduction to daily (T)SVN-usage with best practices and common
use-cases. A kind of condensed manual for our specific environment and
purposes.
As you point out, the SVN manual is a handful... But it really has to
be. It's a general document. When writing an internal corporate
document, YOU can decide on how-to-do-things (policies) where general
manuals have to mention every possible way to do it or none at all.
(Sort of.)
>> Further, it is well known that the error messages from SVN are
sometimes
>> bad and sometimes really bad.
> My post was an attempt at contributing in this direction.
> If SVN gives wrong messages, then please pass them on to the
> SVN community.
I believe that they are aware of most bad messages. They just need
someone to step up and fix it. Maybe you are the one? Enlist at
http://subversion.tigris.org/.
> For the moment, all I can offer is that TSVN should clearly indicate
> which messages come from TSVN and which come from SVN - it doesn't do
> that currently
That's a valid point. Do you have a suggestion on how to indicate this
in an intuitive manner? Remember that in many cases you don't know
(AFAIK) if a message originates from SVN or a hook-script, but maybe
there's a way to find out using the SVN-APIs?
> I have a bad habit of responding to rhethoric questions, so here's
*my*
> preference of the kind of reactions (which doesn't mean it's even
> relevant, just a data point):
...
> 5. Blindly assume it's a noob and give a very wordy, very polite RTFM
> answer like the one given.
Assuming the list was ordered according to preference I guess I didn't
fare all that bad in making the top 5! ;-)
Anyway, I figured that the kind of tips provided in my post is generally
needed on this list with some frequency. But maybe that's just old habit
now that we have a users-list as well?
> No offense intended (or taken - I'll hold in your favor that you felt
> obliged to answer at all, and I know it's all too easy to take some
> given expertise level for granted and be too quick with an answer on
the
> wrong level).
Thank you. I see my mistake now and I'm happy that you didn't take it
personally. Once again best of luck to you with introducing (T)SVN in
your workflow. It can certainly be a powerful ally in times of peril.
Hans-Emil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Jul 4 09:24:36 2006