Kristis Makris wrote:
>> The problem is that Subversion doesn't provide per-project settings at
>> all. So as long as Subversion doesn't have such a feature, we have to
>> use some other means to *simulate* per-project settings.
>
> I am wondering if having only one file that describes the entire
> tortoisesvn configuration for all directories would be possible. Not one
> file per directory, but one file for the entire repository.
We thought about that too. But as I already mentioned: it wouldn't work.
Because not all users have read access to e.g. the repository root where
you most likely have to put that file.
>>> We could try this. I don't know how SVN will react, since in pre-commit,
>>> you are already in the middle of a transaction. You can't (or can you ?)
>> You could add stuff there. But Subversion clearly states that you should
>> not do so (check their docs for reasons why not).
>
> Was it expected by the tortoise propset solution that an integration
> hook will be responsible to always set these properties ? Or was it
> expected that they will always be manually applied by the user ? We are
> trying to avoid any manual steps.
It's expected that users add those manually. Or at least an admin does.
As I said: you should *not* change a commit (by adding the properties)
in a hook script at all.
>>> The problem I see with the entire propset idea in TortoiseSVN is that it
>>> cannot be reliably enforced. Would it be impossible to simply configure
>>> in the TortoiseSVN client these properties (configuration attributes
>>> really) so that they are separate from the repository itself ? Why must
>> Separate from the repository? And how would that work? You can't just
>> set those globally and expect all projects you're working on to use the
>> same bug tracking urls.
>
> No, but you could set "somewhere in the TortoiseSVN client":
>
> - For repository http://some.rep/ apply these properties
> - For repository http://some.other.rep/ apply these other properties
But just above you said that you wanted to avoid "any manual steps".
Having such a configuration would mean that *every* user would have to
do those manual steps.
And if e.g. the url to the issuetracker changes, your users won't even
notice that until something breaks.
>>> Perhaps the client could connect to the server once to get that information
>>> (e.g. from a known file inside the repository), and cache it. Was this attempted ?
>> When should we contact the server? Every time the commit dialog is
>> shown? That would annoy users a lot, because it will make the dialog
>
> Assume tortoisesvn is responsible for adding a file called
> http://some.rep/tortoisesvn.config. If a user checks out
> http://some.rep/trunk then TortoiseSVN could also check out the .config
> file. This file could contain a description of what are now "the
> properties". e.g.
And as I mentioned above: having such a file requires that all users
have read access to that location (usually the repository root), which a
*lot* of projects simply can't allow!
>> If we don't contact the server every time, then what happens if the
>> information on the server changes? No user would get notified of that
>> change and the client app would use outdated/wrong information.
>
> It's not clear to me yet what are the implications of a client app using
> outdated/wrong information. As far as I understand, it means that
> browsing through a log comment, and clicking on a bug would bring up a
> browser that returns a "404 - not found error". This could be detectable
> by the TortoiseSVN client, and an automatic update of the
How could TSVN detect that some other app (we don't know which browser
the user has installed as the default - ok, we could find out, but there
are just too many of them out there) received a 404? Do a screenshot,
hoping that the browser is on top, then analyse the screenshot image and
scan for some "404" text?
> Another problem for the user might be that the log format changed.
> Presumably, the sysadmin also changed an integration hook to accept a
> different format, and the hook script will indicate that the log format
> is indeed different. Again, the bug number format might have changed.
> In any case, the integration hook won't permit a commit. The user will
> ask for help (from the repository admin who initiated "the properties"
> change).
>
> It's my understanding that the user won't be allowed to continue
> committing, and will have to resovle this. I don't know if there are
> other problems. Stefan, can you help ?
It all depends on how you implement the hook scripts. You could even
write in the error message of the hook script how the user can resolve
this, complete with the format of the log or how the properties must be set.
> Also, how often do "the properties" change in a repository ? Compared to
> how often new directories missing the properties are added.
That of course depends on your project. I can't give you any estimates
here because I don't know your project.
>>> Question: How is this implemented in TortoiseCVS ? Is this configuration saved inside
>>> the CVSROOT directory ?
>
> Does anyone know more about this ?
Why? It is completely irrelevant. We're talking about Subversion here,
not CVS.
>>> I don't understand. One could store in a file in the repository this data. And
>>> a TortoiseSVN client would know that it should always attempt to check that file
>>> out first, to get that information.
>> We thought about that too. But that would have to be implemented in
>> Subversion, not TSVN or other Subversion clients.
>
> It doesn't need to be. Someone who commits from subversion has to meet
> the log format of the commit integration hook. This is regardless of
> whether the user likes to have TortoiseSVN integration when using that
> SVN client. If using the bare 'svn' command under UNIX, they still need
> to meet the bugnumber and log message convention. An integration hook is
> always responsible for the final checks.
I wasn't talking here about integrating it in Subversion so other
clients also benefit from it, but from a technical point of view.
Only Subversion can keep an operation atomic. While it isn't a problem
for updates/checkouts of such a file, it is a big problem when
committing changes to that file. TSVN would have to do *two* commits,
which are not atomic anymore.
Also, the same as I now mentioned several times applies here: you can't
guarantee that a user has read access to that file.
Another problem with using files: how do you name that file?
You can't just make up a name and expect all projects to *not* have such
a file with that name already present in the repository.
> I'm suggesting a single file inside the repository, not a file in every
> subdirectory. It would be globally accessible to all users that want
> TortoiseSVN integration.
Again, see my argument above.
> I may be missing something. But it seems that checking out a folder,
> that lacks "the properties", for whatever reason, requires you to also
> checkout the parent folder to acquire them. Checking out the parent
> directory that contains them may mean checking out a large amount of
> data. If the essence of the problem has become how to automatically
> enforce adding these properties on new directories, then we'd like to
> see TortoiseSVN provide a hook that adds them.
>
> If "the properties" are saved in a file, and the user checks out a
> folder, the TortoiseSVN client can automatically check out
> tortoisesvn.config to retrieve them if it is missing already. There is
> no need to add a hook that automatically adds them.
* to get the missing properties, TSVN would have to contact the
repository and fetch that file: that's a *long* round trip to the server
when the user just want's to bring up the commit dialog.
* where would we store that file we fetch from the server?
* how can we be sure that the user has also read access to the parent
folder and we actually can fetch the file? Try and see if it fails? That
means for the user that he has to wait for us to try for no good reason.
> This discussion started as a feature request to always add "the
> properties" using Scmbug hooks. It seems that this shouldn't be Scmbug's
> problem to solve. Perhaps TortoiseSVN should be providing that hook, if
> needed. A pre-commit hook script that rejects the commit when a new
Sorry, TortoiseSVN is a *client*, not a server. Hooks must be
implemented on the server, so we can't provide those.
If you however have such a script (or someone else does), we'd be happy
to include that in our contribs folder in our repository for all other
to be used.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Nov 20 09:34:51 2006