Hans-Emil Skogh schrieb:
> I didn't read your entire post,
OK, if it's too long to read, here are the problems in a nutshell:
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.
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.
I just wanted to avoid jumping to conclusions. Even the above
descriptions may not be fully appropriate.
> so I'm sorry if I'm jumping to conclusions here...
Sorry, but I think that's indeed the case. I wouldn't have gone to the
length of writing down a blow-by-blow account of what I did and what
(T)SVN responded before reading instructions. I don't like to waste
everybody's time, and wasting my own time I like even less.
> First of all I think that you would be better off taking the time to
> read the (IMHO quite excellent) SVN (and TSVN) manual instead of writing
> a lengthy description of how you managed to not follow the instructions
> given in those.
Where did I not follow the instructions?
> Generally, if something does not work the way you assume they do, for
> example if you can't commit a change because of an error message, do not
> try to "fix" it by random interaction with the GUI (for example
> "splitting transactions" as you put it, which generally should be
> avoided). Instead consult the documentation and try to figure out WHY it
> didn't work out as you imagined. I think you will find this approach
> rewarding in the long run.
Yeah, I know.
The problem is that even though the SVN manuals do a great job at not
stating the obvious, they are still too much. 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.
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 :-)
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.
> Further, it is well known that the error messages from SVN are sometimes
> bad and sometimes really bad. But it's not really something that TSVN
> should handle; it should be fixed in SVN. There's already an issue in
> the SVN bugtracker for this so I assume that it's being worked on. You
> might want to contribute to that effort?
My post was an attempt at contributing in this direction.
If SVN gives wrong messages, then please pass them on to the SVN community.
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 (at least not in a way that was obvious for me, and such
things shouldn't require looking them up in the manual - there are
limits to the capacity what can be learned from a manual).
> Lastly, if you do manage to fudge things up in your WC, it might be
> wise to start over with a freshly checked out WC to sort things up.
> You should also familiarize yourself with the repository browser (or
> similar tool) as a viewer to check the current state of the
> repository. And remember, you can _always_ go back to any earlier
> revision in the repository in case you screw up real good. After all,
> that's what versioning is all about!*
I know all of this - including the footnote.
Heck, this isn't the first versioning software I ever worked with.
I've been programming several decades now, so I usually know what I'm
talking about. (Well, sometimes I do not... I'm just human after all.)
> PS. Postlastly, maybe I should have spent the time improving TSVN
> instead of answering this email? :-I DS.
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):
1. Read and understand the post, find the first position where I went
wrong, explain what was wrong about it (or give the URL).
2. Ask for clarification. Or for a summary.
3. Ask how much of the manual I did read, or about my general
background; compose an appropriate answer after that.
4. Leave the post alone.
5. Blindly assume it's a noob and give a very wordy, very polite RTFM
answer like the one given.
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).
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jul 3 16:57:44 2006