I am a HUGE fan of TortoiseSVN. I would not use anything else but
TortoiseSVN in Windows.
I don't use the nice bug text box though, or the linkification, so far.
But I would like to. I want to get spoiled!!
Spoil me!
On Mon, 2006-11-20 at 09:34 +0100, Stefan Küng wrote:
> > 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.
Perhaps add it in http://some.rep/3rd_party_config/tortoisesvn.config.
Then give all users read access to the folder 3rd_party_config. You
won't need to give them access to the root.
The sysadmin will be responsible for adding that 3rd_party_config
directory to "enable TortoiseSVN integration". That's OK. It's a
concious step. The sysadmin is responsible for making the life of users
easier.
> >>> 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.
OK. That's a valid assumption. Now, we are trying to investigate a way
of removing this manual step.
> > 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.
This is true. Having the config on the client side would not be optimal.
Let's all, together, try to see if we can store them in the repository
in another way.
> And if e.g. the url to the issuetracker changes, your users won't even
> notice that until something breaks.
What are the implications of something breaking ? So far, I only see a
broken link in the browser being the problem.
> 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!
As mentioned above, a separate folder holding the 3rd-party tools
configuration could be accessible to all users for read access.
> >> 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?
How about a thread is launched in the background, at the same time that
the browser is launched, that attempts to connect to the url. If the
result received from this thread is a 404, then you automatically try to
fetch a new 3rd_party_config/tortoisesvn.config file.
But even if automatic detection is not implemented, when the user sees
he gets a 404 in his browser he has to execute ONE manual step to
refetch "the properties".
We are proposing only ONE manual step, if the properties ever change.
Compared to MANY manual steps, one every time a directory is added. ONE
rare manual step vs MANY frequent manual steps.
We can't avoid manual steps it seems. But we can make them less
frequent. Stefan, what do you think ?
We wouldn't have to worry about large checkouts of the parent directory
either that had the properties.
> > 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.
That sounds great!
> > 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.
Stefan, really, do you expect properties to be changing more often than
adding new directories ?
I expect properties to be added once, and then many directories may be
added in the future. If the repository is moved to a different machine,
the properties will be changed once in the lifetime of the repository.
But again, folders will continuously be added, and will continuously
need properties maintained for them.
> Why? It is completely irrelevant. We're talking about Subversion here,
> not CVS.
I was wondering if the created something like "the properties". It seems
they stayed away from that altogether.
> 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.
All projects could be using the same, single file that describes "the
properties" for all projects in the repository. Given X projects, you
have only 1 file in the repository.
> > 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.
This has to be executed only once. The first time, if the file is
missing.
> * where would we store that file we fetch from the server?
Anywhere. I'm sure this could be worked out. Have a temp directory for
tortoisesvn config files that are mapped to checkouts. Like a /var in
Unix.
> * 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.
Yes, you could try to see if it fails. If it does, the sysadmin did not
give the user permission to that file. It would have to be corrected.
Throw an error message.
> > 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.
But you are proposing a way of making the client more user-friendly
while you are not providing a consistent approach to guaranteeing that
"the properties" will be maintained in all folders. You would have to
get into the game of writing hooks, if it can be done that way, to
ensure properties are added everywhere. It's your responsibility to
provide a consistent, complete way of doing this.
Or you could change the current way of storing "the properties" and
avoid writing any hooks at all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Nov 20 19:04:13 2006