Stefan, thanks for the insight. Perhaps the questions of this
discussion should be added in the FAQ, or even the answers further
explained.
On Sun, 2006-11-19 at 19:46 +0100, Stefan Küng wrote:
> >> - 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.
It seems that we are looking for a solution to this problem.
> 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 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.
> > 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.
Perhaps that's what Marek's answer should be. But it still requires a
manual step when a directory is added. The user must reset the
properties, correctly.
> > 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
> > 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 thought I had something against a 'version change', but perhaps I
don't. I imagined that if someone told you r1000 is the one you are
releasing, and after 5 mins they tell you it's actually r1002, as a
release engineer you would want to know what the changes were. You would
go out diffing to determine what changed. You could be annoyed if you
realized that two folders just happened to have properties that are used
by an SVN client set to accomodate it. And it could be entirely avoided.
But this may not be such a strong reason to be against a version change.
> > 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.
Assuming you do want to use it, perhaps there may be a *better*, not
*another*, way to do it. We are trying to determine if there is.
Perhaps there isn't.
> 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
Ahhh, I see.
> > 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.
[trunk|branches|tags]/.*=ThePropertiesA
trunk/src/imported_middleware/.*=ThePropertiesB
someOtherProjectC/[trunk|branches|tags]=ThePropertiesC
ThePropertiesA= {
... you describe them in some format.
}
ThePropertiesB= {
... you describe them in some format.
}
ThePropertiesC= {
... you describe them in some format.
}
> 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.
I see the round-trip argument.
> 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
tortoisesvn.config file could be initiated. If "playing automatic
detection games" turns out to be hard or error prone, a user could also
manually update the .config file. They will need to know they must do
it, and it is a manual step that we are trying to avoid. But they would
click one button "Update TortoiseSVN configuration" that would update
only one file.
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 ?
Also, how often do "the properties" change in a repository ? Compared to
how often new directories missing the properties are added.
> > Question: How is this implemented in TortoiseCVS ? Is this configuration saved inside
> > the CVSROOT directory ?
Does anyone know more about this ?
> > 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.
If other Subversion clients, like TortoiseSVN, would like to display a
separate "bug" textbox, and automatically craft the log message to match
the expected convention, then yes, they will need the tortoisesvn.config
file. That's a convention you have well-defined. Others have nothing to
lose from the definition in tortoisesvn.config. They have to implement
some convention, regardless of what that is. If the convention becomes
simpler (one file instead of properties on every directory), they would
benefit from it, too. They are facing the same problem already.
> 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.
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.
> > 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.
I see the 'version change' argument here. But there is something to be
gained from staying away from folder properties...
> 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.
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.
> And no, you have not described a better way. Sorry, but what you
> described was *another* way, not a *better* one.
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
folder is added which doesn't have these properties set may be enough.
Or users may want the properties added for them on a hook (if svn allows
it); again TortoiseSVN should be providing this hook.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Nov 20 08:27:57 2006