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:
>
> 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.
You're welcome.
>> 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?
The one that was current last week 1.3.4.6692 (32-bit).
Possibly more interestingly, the SVN repository behind that is 1.1.4-2,
that's what's current on Debian Sarge. (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.)
> 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.
That's what I tried and what didn't work.
> 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
I can't access this - I'm asked for username and password.
> Provide a step-by-step recipe on a know test-repository and I'm sure we
> can sort this out.
Good.
>> 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.
I haven't ever used the command line, so I'm unsure whether I'll manage.
(Command line isn't a very good option on Windows machines :-( ...)
My usual setup is a subversion server on a Linux box and a TSVN client
on Windows.
> 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.)
Fully agreed.
Actually, all the information that's in the manual has to be somewhere.
It might be helpful if it were moved into the TSVN UI, at least the
technical details. (I know that this is a *huge* amount of work!)
> 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/.
Sorry. My day has just 24 hours, and I'm egoistical enough that I want
to keep the nights for myself ;-)
Seriously, I'm already contributing part-time for PmWiki, helping out a
friend to set up his Star Wars fan site, meddling with political affairs
in a literature association, *and* setting up a business with a partner.
I have shelved a comic translation that I'd really have liked to do for
lack of time.
And that's just the things that are "current"; I have a plethora of
other shelved projects.
Must as I'd like to contribute to SVN, shouldering yet another
time-consuming project is simply impossible for me.
>> 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?
TSVN reports errors as Action = "Error", Path = <error message>.
I could imagine including the point-of-origin information in the Action
column, e.g. saying "TSVN error" or "Repository error" (downside here:
"Repository error" is a too long text for the Action column, and I
wouldn't want to widen it just for boilerplate text).
Alternatively, the point of origin could be added to the Path column, as
in "Repository responded: No such file or directory" for SVN errors (and
no special handling for locally-generated errors). I imagine that SVN
errors go through some common code anyway, so it should be relatively
easy to wrap the error text in "Repository reported: %s".
> 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?
Dunno. I haven't looked into the API (nor would that make much sense - I
couldn't do more than a very cursory skim of the API docs, and that's
usually not good enough for making actually useful proposals).
My knee-jerk reaction would be that it's SVN's obligation to identify
hook messages, by saying something like
/srv/svn/repo/hooks/post-commit: some hook script message
The result in TSVN would then be something like
Repository responded: /srv/svn/repo/hooks/post-commit: some hook
script message
which wouldn't win a Nobel prize for aesthetics, but it would be good
enough for me ;-)
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Jul 4 11:10:51 2006