Philip Martin <philip@codematters.co.uk> writes:
> >
> > # Output is:
> > #M 1
> > #? libs
> > #A libs/wc/2
> >
> > svn ci . libs/wc -m ""
>
> Here you are running a single commit with paths from different working
> copies. That's not supported, it may never be supported. What do you
> expect to happen?
>
> The hard part is that unlike 'svn status', which simply iterates over
> its targets, the commit command combines it's targets and then runs a
> single operation on the result. So at present the commit targets must
> come from the same working copy. Attempting to combine the changes
> from multiple working copies into a single commit is unlikely to work,
> the working copies may be at different revisions, they may have
> different URLs, or they may have conflicting local modifications.
>
> The best I think you can expect is for there to be two separate
> commits, one for each working copy, but that would require code to
> identify to which working copy each target belongs.
Two points:
- In order to get any better behavior, we need the canonical
repository URL or some similar identifier.
- Once we have that, we plan to promise atomicity across the set of
commit targets on a per-repository basis, not per-wc. Because the
commit driver works solely on the URLs of its commit items
(instead of working copy paths) we should be able to pull this
off. harvest_committables and friends is setup to sort the
'things to commit' that it finds into sets based on their
associated repository, and then the commit process iterates over
each set. Of course, currently there is always exactly one set.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 31 16:14:08 2002