I was looking into what it would take to un-do an update of a single file,
assuming that the update had produced a conflict. The <entry> element in
the ".svn/entries" file looks like this:
> <entry
> committed-rev="120"
> name="f2"
> text-time="2005-03-19T05:04:29.000000Z"
> committed-date="2004-12-02T22:53:27.409350Z"
> conflict-wrk="f2.mine"
> checksum="68b329da9893e34099c7d8ad5cb9c940"
> last-author="dworley"
> kind="file"
> conflict-new="f2.2.r149"
> prop-time="2005-03-19T05:06:16.000000Z"
> conflict-old="f2.r149"/>
The (new name of the) old working-copy file is given by the conflict-wrk
attribute. The new working-copy file is named by the name attribute.
The new base revision of the file has the revision specified in
committed-rev, and the URL is specified in the url attribute of the <entry>,
or if there is none (and there usually is none), the url attribute of the
<entry> for the directory itself, which has name="".
The old base's revision isn't stored explicitly, but can be recovered from
the conflict-old attribute. However ... There is no way to discover the
old base's URL. If the operation was an "update", that is OK, since it is
the same as the new base's URL. (Unless the file was moved, but svn doesn't
have real moves yet.) But if the operation was a "switch", you're out of
luck.
And the above example was from a "switch", as you can see since the
revisions of conflict-old and conflict-new are both 149. (An update from a
revision to itself can't cause a conflict.)
I suppose this isn't a high priority, but to support operations like "roll
back an update", it would be helpful if svn defined a "conflict-old-url"
attribute to record the old base's URL if it is different from the new
base's URL.
(The reason I'm interested in this is that sometimes when a conflict arises,
the easiest solution is to "rollback the update, modify your working copy
(in some specified way), then update again". This is particularly common
with formatting. Of course, the user could do it all manually with a merge
tool, but this is a more user-friendly approach.)
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 22 00:38:00 2005