kfogel@newton.ch.collab.net wrote on 05/27/2005 03:37:27 PM:
> SteveKing <steveking@gmx.ch> writes:
> > That way, Subversion can implement the log message template as
> > proposed with the hook script on the server.
> >
> > The only thing I request from you guys is that once inherited
> > properties are implemented, you define a property which does the same
> > thing as the TSVN project property I will use until then.
> >
> > I hope we can all live with such an implementation?
>
> Well, I think this is premature -- we haven't decided on the hook
> proposal yet. We might still end up doing inherited properties.
I just thought I would point out that the "LMT" feature is not necessarily
tied to "iprops". It could also be implemented with plain-old properties
as they exist today, and as TortoiseSVN and Subclipse implemented it.
"iprops" simply makes this easier for the end-user to implement as they
can just set the property at a top-level location and let it be
automatically propogated to the sub-folders.
In the case of Subclipse, the current property system isn't hard to work
with, because when working in the Eclipse IDE, there is always a
very-specific top-level folder that you have to checkout. So those are
the only folders that need to have the properties set. In a project like
Subversion where any folder in the repository could be the root of a
checkout, then the properties would essentially have to be set on every
folder if you cared about the feature.
Bringing this back to "LMT" we could discuss the pros/cons of using
properties in general, which implies a static template system. If in some
future release, iprops are implemented, it just makes this particular
feature easier to setup.
IMO, static templates would meet the needs of the majority users and
cases. I also think a simple template resolution mechanism, as used by
TortoiseSVN would accomodate most users and cases. If you want to satsify
all cases, then a dynamic system seems like the only possibility.
Personally, I think the dynamic system might be overkill, but it could
well be that you have a lot of requests for it queued from CollabNet
customers.
The irony here, is that I still think that if you go with the dynamic
approach, you are going to have to supply a sample hook that is driven by
properties stored in the repository. If it isn't, then I doubt you will
see many hosting services provide a hook as they are not going to want to
maintain the hook for every customer.
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 Fri May 27 22:28:26 2005