David Weintraub <qazwart@gmail.com> writes:
> Subversion only talks to the server during particular instances such
> as an "svn update" or "svn commit". In between, the changes that the
> client needs to let the server know about have to be stored somewhere,
> and that's in .svn. To clarify, I'm talking about storing revision
> properties via a "svn propset --revprop --nextcommit PROPERTY VALUE"
> type of command. You would set the various revision properties you'd
> want to do on the next revision, and then run the commit. That way,
> you could do an endless variety of revision properties without
> worrying about piling them on on top of the command line.
Now I see what you mean, thanks.
> The strange thing about the "svn propset --revprop" is that it sends
> its information directly to the server while the regular "svn propset"
> stores its information in the .svn directory One uses mainly libsvn_wc
> to do its work while the other uses libsvn_ra. Although the syntax is
> the same, the two propset commands really act in two completely
> different ways.
The reason for this is that, because regular properties are versioned,
we subject to them to the same out-of-dateness check as we do file
data. You have to make your change "against" some specific base
revision of the property, and if that base turns out to be
out-of-date, then your change will be rejected. That's why directly
regular properties on URLs is not allowed: the out-of-dateness check
would not be possible, and the user would have no way of knowing what
she might be overwriting, even if she did a propget right before.
> Maybe that's why everyone is talking about setting revision properties
> with the "svn commit" and would probably be the quickest way to
> implement it. After all, revision properties are set right now during
> the commit process (svn:log, svn:author, etc)
> All we really need is a good UI...
>
> How about something like this?
>
> svn commit --revprop <KEY>=<VALUE>,<KEY>=<VALUE>,<KEY>=<VALUE>
Indeed, that's what I thought you were proposing originally.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 23 07:24:45 2005