David Weintraub <qazwart@gmail.com> wrote on 06/21/2005 04:52:47 PM:
> On 6/21/05, Mark Phippard <MarkP@softlanding.com> wrote:
>
> There really shouldn't be a problem with errors if the syntax used the
> "--nextcommit" command line parameter. You couldn't accidently set the
> wrong revision parameter in this case.
What I was getting at was that there is an indeterminate time lag between
when you run this command and do a commit. Therefore you could
conceivably set a rev prop, forget that you did and later commit it with
other changes. After thinking about it more, I do not think that would be
that big of a problem. GUI's would have to show this info in some form
any way, so there is no reason it needs to be invisible.
> I haven't had time to really play around with it, but I was already
> informed that the bindings for setting properties on the next commit
> transaction is already there. I could write my own Perl script to do
> this even though the "svn propset" command can't.
I could be 100% wrong, but I think you misinterpreted the comments a bit.
AFAIK, the API and bindings that exist could only realistically be used
within a hook script. They would not work from a client over ra_dav or
ra_svn, they would only work on the server. You could use these bindings
to write a pre-commit hook that parses bug numbers out of a log message
and adds them as revision props, but not to write something that lets the
programmer set the props themselves as part of the commit process.
> I also don't see why it is a problem of "forcing" the GUI clients to
> run two commands. That is, if they don't use the bindings, but instead
> run the commands from the Subversion client. If they were setting
> regular file properties, they'd be doing the same thing.
What I was getting at was that you take a commit option and get a GUI
commit prompt. Only when you click OK would the GUI run these commands.
What I was thinking was that the GUI would essentially be modifying your
WC as part of the commit process and that does not seem like a good idea.
In thinking about it, since these are unversioned props, that really is
not the case, so again, probably not an issue.
> > The spec calls for the GUI to search up the WC hierarchy to find the
> > properties.
>
> Yes, but only if you checked out the parent folder! I find myself
> creating subfolders, then creating a new working directory from that
> folder. If the parent folder that contains the neede properties isn't
> checked out, the commit comments are wrong, and the integrated bug
> tracking system doesn't work.
You basically just restated what I said. If your project is such that
there are only a couple of common "roots" where users would checkout, then
that is the only place you need these properties. People doing IDE
development, or something like Java where the folder structure matters
would likely fall in this camp. A project like Subversion would likely
need the properties on every folder, or at least a lot of folders.
> The document mentions that you should have the developers always
> checking out from the trunk to make sure it will work.
If it does, it is just being sloppy with words. There is nothing about
"trunk" that applies. It simply means project "root". This could be
trunk or a branch equivalent, or it could be several layers down.
> Implementing a query language is always difficult. I figured that if
> the "svn log" printed the information in an easily parsible format,
> you could quickly find what you're looking for -- even without a query
> language. If this could be implemented in Subversion 1.3 without a
> query language or Subversion 4.x with a query language, I'd go for the
> earlier release.
I obviously want, or wanted, this feature too, or I would not have
initiated the original issue. I was just trying to level set your
expectations here. I think that your idea produces a better UI, but I
actually think it would be far more code to implement then doing it as
part of commit. If the feature were implemented the way you suggested,
then there is a lot of work that you would have to do, that you would not
have to do if it were part of the commit command itself:
a) The properties would have to be persisted in some format, likely
inside the WC.
b) tons of other UI would likely be effected. You need to be able to
list and delete these props, svn st potentially needs to show pending
props, svn revert potentially has to do something. Other commands like
svn switch could be impacted etc...
c) Are the props associated with some "target" such as a folder? For
persistence reasons it would seem like they would need to be. If so, then
what happens if I then commit a specific file several layers below it in
the hierarchy. The GUI tools in particular exercise the API's a bit like
this.
etc..
Assuming the current API only works on the server, then regardless of the
UI, there is work to add this capability throughout all of the various
layers to make it work. My point being, I think that this is far from 90%
there already.
Sidestepping for a minute, if this were implemented the way you suggested
(which I think is cleaner as a UI) I wonder if that feature could be
utilized by a merge tracking feature? In other words, if I run svn merge,
the merge process could use this feature to store some revision properties
about the merge that would be committed when I later perform my commit.
That sounds appealing, but I am not sure that versioned props couldn't
serve the same purpose.
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 Wed Jun 22 02:21:33 2005