John Peacock <jpeacock@rowman.com> wrote on 05/19/2005 09:42:12 AM:
> I hate to keep carping on this, but I think the real discussion for
> server->client configuration should start with inherited properties
> (files inherit from their containing directory; the server manages
> directory inheritance on checkout). This more generic feature would
> give us a way to support autoprops, directory-based log templates, and
> other distributed property features.
It is hard to know which message to choose to reply to. I will just lump
all my replies in this one message:
1) Using Properties for Commit Message Template
Absent any other way to achieve this feature, this is how both Subclipse
and TortoiseSVN do it. We both use a property named tsvn:logtemplate.
This works pretty well. The only problem is if you have a repository
where you do not really know where users will checkout from, you have to
set the property on every folder. As John says, if there were some form
of inherited properties, that would make this a much more viable solution.
2) Server-side hook
I do not have strong feelings on this. I just ask that you please
consider the GUI tools. We have our own UI for gathering the log message,
so we will need an API we can call to generate the template prior to the
commit. A potential problem for Subclipse and TortoiseSVN is that our
commit dialog lets you control what is being committed. So the dialog
will initially populate with all of the potential files that can be
committed (including unversioned files), but the user can then change what
will be committed via the UI. So passing the file names will be
problematic. TortoiseSVN also allows you to start typing your log
messages while the list of files to be committed is still being
calculated.
3) Server -> Client Configuration
I am sort of in agreement with some of the other comments that have been
posted. I cannot ever recall someone asking about commit message
templates. What I always here is people wanting auto-props. It could
also be used for other configuration that doesn't even currently exist. An
example, both Subclipse and TortoiseSVN support a "standard" we developed
for bug-tracking integration.
See: http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt
We had to use properties to store the configuration for this. It works
OK, but has the same problems as I listed in comment #1 above. Inherited
props could solve this problem. What we were really looking for was some
way for the server to broadcast this configuration to the client.
4) Configuration conflicts
I have not seen this discussed yet, so I thought I would raise it. Setting
aside commit templates and moving on to other configuration items, when we
have server-side configuration do we just remove client-side
configuration? If we do not, then how do we deal wih the scenario where
both the server and client have the same configuration item defined, such
as auto-props?
5) Personal opinions
I like properties. They are versioned and there are good interfaces
available for manipulating them. They also exist in the WC so you do not
need a server round-trip to interrogate them. If there were just some way
to have properties automatically propogate down a tree hierarchy --
"inherited properties", then this basic feature is a very easy way to add
a lot of functionality both to the svn command line, but also GUI tools
which may want to use the same feature in ways the command line does not.
The only "problems" that cannot be solved one way or another by using
properties are the configuration items that apply to svn import since
there is no WC. That could possibly be solved by having import retrieve
properties from the server before the import.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 19 16:08:35 2005