[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn mv" on non-empty directory --> "WC not locked" or "txn out of date"

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2003-11-01 00:11:55 CET

Ben Collins-Sussman <sussman@collab.net> writes:

> On Fri, 2003-10-31 at 16:16, Gareth McCaughan wrote:
>
> > How difficult would the following be? (I'm guessing that the
> > answer is "altogether too difficult".) In txn_body_commit,
> > before giving up because a txn is out of date, check to see
> > whether the two revisions are "the same" (i.e., nothing has
> > changed between them). If they aren't, then we report
> > SVN_ERR_FS_TXN_OUT_OF_DATE as at present. But
> > if they're the same, then we allow everything to go ahead.
> >
> > We must be able (in principle) to tell whether anything has
> > changed, because otherwise "svn status" wouldn't work.
> > It naively looks to me as if svn_fs_contents_changed will
> > determine this.
> >
> > Doubtless I'm being *very* naive here. Enlighten me ...
>
> I think I'll let cmpilato field this question... :-)

If I understand the proposal, you're effectively talking about a
content-based merge of sorts, allowing a potential conflict to "slide"
if the result would be effectively a no-op. This would be a royal
pain, not so much because of the calls to
svn_fs_contents_changed()[1], but because of the patch-up to the
'changes' table that would be required -- you can't give credit for a
change to a transaction that didn't actually affect the change.

[1] svn_fs_contents_changed(), by the way, probably won't be
    sufficient for the needs here. If we're talking about directory
    nodes here, deleting an entry from a directory will tweak its
    DATA-KEY, and svn_fs_contents_changed() will bail right there --
    it doesn't actually attempt to contextually compare contents.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 1 00:12:59 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.