On Mon, Feb 25, 2008 at 8:09 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> kmradke_at_rockwellcollins.com wrote:
> > Ok, I think I'm convinced to go with --base-rev instead of overloading -r.
> > I'm also convinced that the rev should be "tolerant" as well. I.E. if
> > the property hasn't changed since the specified version, go ahead and
> > perform the operation.
>
> So, I haven't reviewed the previous patch, but I'm a bit intrigued by this
> talk that implies you'll be hand-coding the revision-based verification.
>
> Our RA commit editor implementations should already have logic in place to
> bounce commits to out-of-date files and directories. You need only to use
> the BASE_REV value (if provided; otherwise, go fetch HEAD from the
> repository before the commit and use that value) as the BASE_REVISION
> parameter to the likes of editor->open_directory() and editor->open_file(),
> right? In doing so, you are telling the repository that the changes you are
> transmitting are made against that version of the resource. If it detects
> that the version is out of date for the types of changes you are making, it
> should bounce the commit. I mean, our whole working-copy commit system is
> predicated on these types of checks existing and functioning correctly.
>
> But perhaps I misunderstand your ideas of being "tolerant". Is the existing
> out-of-dateness checking too restrictive?
Yes, that is how propedit-on-URL support works. Implementing this
feature is as simple as passing the right base_revision_for_url
argument to svn_client_propset3.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-25 18:07:05 CET