>>> 1. Moving subdirectories is readily accepted by TSVN, but when
>>> committing that change, TSVN will fail.
>> I can't reproduce that with my setup. What version of TSVN are you
> The one that was current last week 188.8.131.5292 (32-bit).
Ok. Good. *Should* work. Maybe someone else running the stable build can
> Possibly more interestingly, the SVN repository behind that is
> that's what's current on Debian Sarge.
I don't think that matters too much. SVN should be compatible over the
1.x-range, and I have heard no issues like this one before. I'm sure
that there are lots of people running stable Debian servers around here.
> (Hmm... it might be useful if the repository browser
> provided that information, and/or near the URL
> display on the Subversion pane on the Properties dialog.)
Indeed it would. Again a question of if the SVN API would allow us to do
that, and I'm not really qualified to answer.
But then again, *mostly* the server version is of minor importance.
>> Can you reproduce this using a simple dumy-repository? For example
> I can't access this - I'm asked for username and password.
You can use that script right away or build a custom one based on it.
>>> 2. There are several actions that can get TSVN into a state that's
>>> inconsistent with the repository's state. This is... er...
>>> even if the inconsistency seems to be fixable via the Update
>> This is *very* unsettling to say the least. If you find any such
>> please provide a step-by-step reproduction recipe using the command
>> client and post it to the SVN-project.
> I haven't ever used the command line, so I'm unsure whether I'll
> (Command line isn't a very good option on Windows machines :-( ...)
As you have read the SVN manual I'm sure you will! You can use the
Command Line Cross Reference from the TSVN-manual to get you on your
(But I'd suggest simply trying to figure it out using the SVN-manual.)
(And yes, commandline on windows IS kinda awkward, but fully functional
for SVN purposes...)
> My usual setup is a subversion server on a Linux box and a TSVN
> client on Windows.
That's my preferred setup as well.
>> 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
> Sorry. My day has just 24 hours, and I'm egoistical enough that I
> want to keep the nights for myself ;-)
Sounds like a good policy =)
>>> 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
>>> that currently
>> That's a valid point. Do you have a suggestion on how to indicate
>> in an intuitive manner?
> TSVN reports errors as Action = "Error", Path = <error message>.
> I could imagine including the point-of-origin information in the
> column, e.g. saying "TSVN error" or "Repository error"
Hmm. That could be an idea. But then we would have TSVN, "SVNClient" and
SVNServer errors. Would that maybe be confusing for the user?
...but maybe the positive aspects outweigh the negative here. Comments
from any of you other guys? Would it be worth the effort to identify
where the actual error originates?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Jul 5 10:34:59 2006