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

RE: AW: How to find out the rev number where a file was deleted?

From: Ludwig, Michael <Michael.Ludwig_at_delphi-mb.de>
Date: Tue, 30 Nov 2010 12:21:13 +0100

> -----Original Message-----
> From: Les Mikesell
> On 11/29/2010 11:45 AM, Ludwig, Michael wrote:

> > I can see that from the peg rev point of view, HEAD is the
> > future. But I think we can also agree that from the SVN user's
> > perspective, every single existing rev including HEAD is in
> > the past.
> Yes, but from the perspective of getting history where you can
> only go backwards, you have to specify the right starting point,
> and a rev where the thing doesn't exist isn't the right place.

Certainly. Just imagine you weren't required to specify a revision:

svn show svn://server.dev/eins/zwei/drei/vier.txt

 seq node-id revision status
   1 1bca349 33 A
   1 1bca349 75 M
   1 1bca349 76 M
   1 1bca349 111 M
   1 1bca349 188 D
   2 4941b20 1099 A
   2 4941b20 1101 M
   2 4941b20 1108 M
   2 4941b20 1831 D
   3 6e6cdff 18004 A
   3 6e6cdff 18014 M

The node ID would identify the versioned object. (I don't know
anything about what the node ID might look like; the example is
just a wild guess.) This sketch certainly has flaws, but is it an
unreasonable proposal? Users might find it useful.

> > Yes, there could be several items - several revision ranges -
> > in the index, pointing to several unrelated objects. But is it
> > a big problem?
> Yes, if you are in the habit of deleting things and adding them
> back, then wanting one of the deleted versions.

You'd read it from the list and identify it by revision. No
changes to existing behaviour and functionality.

> > In database speak, we'd indeed have a compound key for
> > *uniquely* identifying an object, with the first part of that
> > compound key being the URL, and the second part the revision.
> > But if we don't know the revision, we simply use the URL alone
> > and receive a list of all the items ever to have appeared at
> > that URL. Which ones we're interested in is then a matter of
> > human decision; but gone is the tedium (or wasteful scanning)
> > of establishing the list in the first place.
> That's a reasonable thing to want, but perhaps not reasonable
> for the server to deliver. Would you expect your database to
> find things for you if you renamed or deleted the table holding
> them?

I wouldn't. But if I had a trigger to log changes made to a table
to a log table I'd expect the system to know the table history.
That's maybe a bit more aligned with what I might expect from a
version control system.

> >> A thing with the same name added later as a replacement may
> >> have nothing in common with the item you want. I'm not sure
> >> what the right test for this would be other than asking for a
> >> log with a rev range and a peg rev to anchor it to one
> >> specific version.
> >
> > Give me a listing of the things and either require me to
> > specify which one I want or show them all in full detail,
> > depending on the circumstances. In the special case where
> > there is only one item in the list, no further precision is
> > needed.
> It's a big order to make that happen through a client-server
> connection that has no such existing concept and no server side
> hints to do it efficiently.

I agree the server side needs to have the URL index to do it
efficiently. Given that index, however, it shouldn't be difficult.
I wouldn't redesign the existing set of commands, just provide
one in addition that provides the history of a URL.


Received on 2010-11-30 12:21:53 CET

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

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