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
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
