> 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?
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-02-25 17:10:03 CET