"C. Michael Pilato" <cmpilato_at_collab.net> wrote on 02/25/2008 10:09:42 AM:
> 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.
Um, no. I try and do as little extra work as possible... :^)
> 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?
In the patch, it was just passing BASE_REV as the user specified with -r.
I was planning on fetching HEAD and passing that value in if no value
was specified.
However, if the specified BASE_REV != HEAD, I was also planning on
fetching the HEAD value and comparing to the specified version value
and passing in HEAD if the value itself hasn't changed (but
something else has.)
Is that still too much work?
(This last part is what was considered "tolerant". I.E. you specified
10, but the value your are setting/deleting/editing hasn't changed, even
though HEAD is now at 15).
Kevin R.
---------------------------------------------------------------------
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 17:40:12 CET