Re: The "entries" file and un-doing an update

On Mon, Mar 21, 2005 at 03:56:00PM -0500, Dale Worley 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.)

For your given example:

svn revert f2
svn update -r rxxx f2

(I'd give the exact rev for the update for f2 but your example is messed
up. You have the same rev for the old and the new and it's newer than
the rev you updated to).

I don't see any reason to complicate the client by adding something that
can easily be done with two commands...

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org