Hi Marek. After delving into this deeper, I ended up disliking the way
TortoiseSVN does things.
I hope the'll clarify some things for us. Or change their implementation
if needed.
On Sun, 2006-11-19 at 16:10 +0100, Anna / Marek Latuskiewicz wrote:
> OK
>
> I think I finally figured out how it works - and although the solution for
> now is not ideal due to API limitations, it works. The more desired solution
> will be possible as soon as
>
> svn propset will be allowed. There were numerous requests for that and I'm
> going to add one to the pile.
What do you mean by "svn propset will be allowed" ? Where ? In Scmbug ?
Or as being applied remotely in an SVN repository ?
> So the links are displayed by TortoiseSVN if:
Agreed.
> 1) So the solution for that - as you know we can use that:
>
> svn propset -R bugtraq:label "BugzID:" . svn propset -R
> bugtraq:url "http://your.fogbugz.url/default.asp?%BUGID%". svn
> propset -R bugtraq:message "BugzID: %BUGID%" . svn propset -R
> bugtraq:number "true" . svn propset -R bugtraq:warnifnoissue "false" .
> svn commit -q -m "Added BugzID properties to the repository"
>
> But it has several drawbacks:
>
> - You just can not introduce it to the repository with many branches
> or labels as it can mean TerraBytes to be checked-out
>
> - It creates a new version of EACH file in your repository
After reading all this, I'm wondering if it's worth adding a
pre-revprop-change hook. But in any case, this would only solve the
large checkout problem.
> - If you create new projects / directories you must remember to add
> it
Is this necessary ? Won't the properties be picked up from the parent
directory ? Well, I suppose not, if it was a directory way up in the top
of the repository.
This makes me wonder how the TortoiseSVN people envisioned this to work.
Have they foreseen all these limitations you discovered ?
>
> 2) One possible solution is to add it to the repository in pre-commit
> scripts but to each file parent directory:
>
> - it would add extra the code to scripts
>
> - user would need to update view after that.
>
> - every change will be the local one
>
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 ?)
add more stuff in the transaction; you might need to initiate a new one,
which then makes me wonder if this will cause problems with the existing
one.
> 3) A brute solution - want to have links? Run this bat in your main project
> directory:
>
> svn propset bugtraq:label "BugzID:" .
>
> svn propset bugtraq:url "http://wawntdev1/mantis/view.php?id=%%BUGID%%" .
>
> svn propset bugtraq:message "BugzID: %%BUGID%%" .
>
> svn propset bugtraq:number "true" .
>
> svn propset bugtraq:warnifnoissue "false" .
>
>
>
> Please notice - no recursion so only a new version for the main directory -
> the rationality of this solution is that 99.95% times it makes no sense to
> check-out subdirectories in project. If for some reason you need that just
> run the script again. Please notice that the operation is that easy that it
> can be done by a project leader.
>
>
>
> Kristis: Do you think that we are able to implement 2) gracefully basing on
> 3) - only attributes for parent directories? Is there a way to avoid updates
> after adding properties in pre script?
QUESTION FOR TORTOISESVN PROJECT: How did you envision this to work ? Do
you expect the user to continuously, recursively apply these properties
every time they add a directory ? Do you expect a Subversion hook to
continuously maintain these properties ?
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
they be versioned properties ? What if you move your repository to a
different machine ? Must you change the properties in the repository,
initiating a version change ? Why ? The machine move is not tied to any
change in your source code.
I'd like to see a well-thought out plan from the TortoiseSVN team about
this. I've just re-read their document:
http://tortoisesvn.tigris.org/svn/tortoisesvn/tags/version_1.2.0/doc/issuetrackers.txt
And I have some comments:
1) In II:
"- When the user enters a log message, a well defined line including the
issue number associated with the commit can be added by the client
automatically. This reduces the risk that the users enters the issue
number in a way the bug tracking tools can't parse correctly and
therefore won't know that the commit was associated with a specific
issue. The users won't have to remember the format they have to use for
each log message and each individual project - the client will take care
of that."
First, if the users enter the issue number in a way the bug tracking tool
can't parse it correctly then the hook itself can catch that. In fact, in Scmbug
a configurable regular expression describes the format of the log message and bug
number.
Secondly, the TortoiseSVN client can still perform that checking WITHOUT consulting
svn properties. They can consult a client configuration. The bug-number format is
NOT a property of the repository. It's a property of the bug-tracker. It shouldn't
be stored in the repository.
2) From the FAQ
"Q: Why don't you use a config file located on the server or revision properties
instead of folder properties?
A: A config file located on the server and revision properties would mean that
a client would need to connect to the server each time the bugtracking
information is needed. On slow connections, this can take several seconds and
would make the GUI respond slower."
Perhaps it shouldn't do that at all. It's the responsibility of the integration hook
to check the format of the issue number and log message. Not the SCM client. And not
the SCM client's frontend.
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 ?
One might argue about the user-friendliness of providing a separate textbox called
"Bug number" in TortoiseSVN. There's nothing wrong with that, as long as it's a local
client configuration. Or can be retrieved once and won't cause other problems. In any
case *****the information needed to do this should not be tied to versiouned
source code changes******. The 'propset' way of doing things right now is tied with
versioned source code changes. It doesn't need to.
Question: How is this implemented in TortoiseCVS ? Is this configuration saved inside
the CVSROOT directory ?
3) From the FAQ:
"Q: Isn't there a way to store the data in the repository, but having it also
stored in the working copy?
A: Subversion doesn't provide such a feature (yet). And there's no way to be
sure that there ever will be such a feature. So we have to make use of that
what's already available.
Also, if the properties are set for each folder, then you can assign a
different bug tracking tool for a subfolder if you want to. Or you can
provide a different URL for each folder."
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.
This information is not tied to source code changes. It is tied to a change in a
single configuration file, that does not even need to be stored under /trunk.
You could still provide a different URL for each folder, if that URL description
was stored in a file in the repository. It does not have to be tied with the
properties. A major limitation discovered by Marek in his research is that if
you add a new directory at the top of the repository, you must manually add
the properties again.
4) From the FAQ:
"Q: But if I have many folders, I have to add those properties to each one of
them! Isn't there a better way?
A: Sorry, but no. But if you can be sure that each user checks out only from
e.g. /trunk/ and not some subfolder, then it's enough if you set the
properties there. The clients will search for those properties the path up
to the working copy root for those properties."
I think we just described a better way. What if you are not sure a user
checks out only from '/trunk' ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Nov 19 18:24:53 2006