Stefan, thanks SO MUCH for the link to the Subversion bug requesting
this.
On Thu, 2006-11-23 at 18:54 +0100, Stefan Küng wrote:
> > *** Do you think the above could work ?? **
>
> Yes, it would work. But it has serious drawbacks. We've considered such
> a solution before and have rejected it:
> for every update/merge/commit/... we'd have to do a second
> update/merge/commit/... either just before or after the original
> operation (to sync that folder).
I understand this argument. Ideally, we want to "sync" the configuration
file during every operation, to avoid manual steps. Else the properties
might be out-of-date. Please see below for a response.
> * this will slow down every operation
> * since there are *two* operations instead of one, the user might have
> to provide two times the authentication (if the auth data is not saved,
> which a lot of people do for various reasons).
> * those operations won't be atomic, which would bring us back to one
> important reason why Subversion was even invented: CVS had this drawback
> and had to be replaced because of this.
These are all valid arguments against implementing this on the client
side. The general consensus seems to be that Subversion should provide a
solution to this.
> * how to name that folder? Just picking one is dangerous: some projects
> might already use that foldername.
I don't think this is a problem. It could be a configurable option on
the client side, in the beginning, if they chose to enable "TortoiseSVN
integration". In any case, some convention/agreement will be reached.
> > 2) The user applies an svn copy directly on the repository (remotely). I
> > don't know how the bugtraq properties are received for that. Can you
> > help ? Would this be a problem ?
>
> If the repository browser is started from the working copy, TortoiseSVN
> uses the properties read from that working copy, even if the operation
> done in the repo browser is remote-only.
> If it's not started from a working copy, we simply don't use the
> properties. Reading them (or a config file) from the repository before
> any operation would take too long.
I see. In any case, properties vs config file does not make a
difference.
> (have you even used Subversion before? I think you would know that if
> you have)
No, I drive a Toyota!
I'm still waiting for my smile :)
> >> You also might have noticed that the file describing the bugtraq:
> >> properties couldn't have been written in one day. That's an indication
> >
> > I don't understand what you mean. Could you clarify please ? Are you
> > saying that the file would be complicated for a user to write manually ?
> > If so, perhaps a window from the TortoiseSVN client could make this
> > easier for the user.
>
> * that file is not for users but developers who want to implement the
> same feature
True. It's for "repository administrators", not users. Perhaps a tool
that helps them put it together could be used. Built either by
TortoiseSVN, or by other projects, as long as the format is agreed on.
It seems that TortoiseSVN gets to define the format, since it got here
first.
> But please, go now to the Subversion mailing list and ask them to
> finally start working on those issues. As long as I'm the only one
> asking for it, they won't think it's that important. Only if more people
> ask for this, they will notice that it's an important feature.
> http://subversion.tigris.org/issues/show_bug.cgi?id=1974
I agree that Subversion should provide the feature of a server side configuration.
You proposed to them to implement it as a configuration file, too. Would it be
fair to assume that when it gets implemented, it will be implemented as a
configuration file ?
When that happens, TortoiseSVN would have to implement what we just proposed. The only
difference would be that TortoiseSVN wouldn't be responsible for "syncing" that file. How
about implementing TortoiseSVN configuration with a config file now, even though it will
remain out of sync ? If this was available as an option for Marek and me, we would use it.
If there was a checkbox in the TortoiseSVN client that let us pick between the "default"
propset implementation, and the "different" config file implementation, that would be great
for our needs.
I'm willing to accept the answer "we don't want to implement it, because Subversion may decide
to implement server-side config in a non-config-file way (more propsets maybe), and our effort
could be a waste of time." But I'm not willing to accept "this is the best we can do right now".
We are trying to understand the root of the problem. If we must investigate the "likelihood" of
Subversion implementing this as a config file, we will. But please don't casually dismiss us
just because we are rude, stubborn, and obnoxious :) If Subversion agrees to implement this
as a config file, in the future (not now), would you be willing to provide a TortoiseSVN
integration implementation that reads data from a config file ? If a "synced" config file
was provided in the future, you would have to implement this anyway. In a sense, you would
implement it now, just not being synced.
Having a config-file, that remains out of sync (the user must manually update it if they discover
themselves that browsing won't work) would be very valuable for a lot of
people's development environment, right now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Nov 24 19:56:19 2006