Kristis Makris wrote:
>> - 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
Wrong. You must set the properties on *folders*, not files.
> 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.
They *are* picked up from the parent directory, but of course only if
the parent directory is checked out too. It doesn't work if you have
only *that* directory checked out, because the properties are read from
the working copy without ever contacting the repository.
> This makes me wonder how the TortoiseSVN people envisioned this to work.
> Have they foreseen all these limitations you discovered ?
We have. Believe me, we did the best we could. The current solution is
the best we can think of.
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.
> 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).
> 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 ?
Most projects do this manually. Because in most projects, you don't add
new folders that often. But you could write a pre-commit hook script
that rejects the commit when a new folder is added which doesn't have
these properties set.
> 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.
> 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.
What do you have against a 'version change'? It's only a new revision!
And you won't run out of revisions in your lifetime. Even if you do a
commit every second, you wouldn't live to see the repository running out
of revisions.
> 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.
That's why there's also the bugtraq:logregex property.
> 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.
Yes it should be. But you don't have to use that if you don't want to.
> 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.
You can do the check in your hook if you want. Nothing is stopping you
from doing that. But people insisted that the client should also check
it, and I think it's a good idea if the client does it too. Because it's
very annoying if you try to commit and have the commit rejected just
because you mistyped the issue number/id. It's a lot easier if the
client just tells you right away that the issue number/id is wrong.
> 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
wait about a second (at least!) for the whole round-trip to the server.
And that's assuming you're on a very fast connection to the server.
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.
> 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.
If you have a better idea that will actually work and not annoy users,
please step forward and tell us. It's not that we didn't think this
through, you know.
> 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.
We thought about that too. But that would have to be implemented in
Subversion, not TSVN or other Subversion clients.
And you haven't thought about per-directory access: some projects (in
fact: more than you might think) restrict access for their users only to
specific subfolders of the repository. That means those users couldn't
access a file stored e.g. in the repository root. You would need such a
file in every subdirectory - and then you're back to the folder properties.
> 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.
But a change in that file would also have to be committed. And that
commit would create a new revision. So you won't gain anything - it's
the very same with the folder properties.
> 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.
Tell me please what's the difference of storing the info in a file or in
a folder property? But before you answer that, think about it first.
> 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' ?
Then you have to apply the property to every subfolder as stated in the FAQ.
And no, you have not described a better way. Sorry, but what you
described was *another* way, not a *better* one.
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 Sun Nov 19 19:47:38 2006