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