On Mon, 21 Mar 2005 15:56:00 -0500, Dale Worley <dworley@pingtel.com> wrote:
> 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.)
Maybe I'm not understanding you completely, but what's keeping you
from renaming file.mine to file and deleting the file.r## files?
---------------------------------------------------------------------
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:44 2005