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

RE: Checkout files from a deleted/moved directory: problem

From: Gale, David <David.Gale_at_Hypertherm.com>
Date: 2006-02-23 22:36:12 CET

(Yes, I'm still trying to keep this conversation on the list.)

Jean-Yves Avenard wrote:
> But when you're looking at revision #10 (as an example)
> at that point in time, if the file foo existed it only existed in one
> place under the name foo...
> If foo was later renamed foo2 during revision #22 then it's not
> relevant to #10.
> Mind you, i;m not trying to start an argument, it's just that as it
> is, the revision # change from the general understanding that i had
> so far: a revision # define a single view at any point in time

But you're assuming you *know* that it was named foo at revision 10.
How do you know this? Did you dig through logs? Get wisdom from the
white-bearded guru who has been around since before the dawn of svn?
Peer into your magic crystal ball?

Yes, if your project is young, and you don't have many developers, and
files don't move very often, you can probably tell fairly quickly what a
file was named once upon a time. But you'll find that, as the project
grows, developers come and go, branches are created, merged, and
destroyed, determining the history of a file will get steadily more
difficult. Subversion tries to help this process by letting you say,
"Well, I don't know for sure what the file was then, but I know what it
was at this other point in time." File renames are important. Let me
give you an example:

Let's say, inside of the repository is a file "foo", which is actually a
back-door put in place by a disgruntled programmer, in case he got
fired. This is closed by deleting the file in revision 354122. Two
weeks later, management wants to know who the programmer was who created
the file, so they can, in fact, fire him. "svn log foo" doesn't work,
since the file no longer exists. Someone points out that it existed at
revision 354121, so they try "svn log -r 354121 foo", but since it
wasn't changed in that revision, the log would come up empty (under your
proposed "fix" to subversion; the current system would still error).
How would you propose they find out who created the file, and who has
modified it since, without doing a log dump of the entire repository?
Now, assume the devious programmer wanted to be cautious, and so
periodically renamed the file--how would you track down what he did?
(Bonus exercise: how would you track this down, assuming a CVS
repository instead?)

Naturally (since I concoted this example to prove my point), the correct
answer is "svn log foo@354121", which gives all the log info for that
file, from its first creation to it's final deletion, complete with all
the renames it underwent along the way.

I'm not sure how this breaks your mental concept of revision numbers, as
they do, in fact, represent the state of the entire repository at a
given point in time. Peg revisions just give you a way of saying, "I
don't know what the file was called at the point I'm interested in, but
I do know that it's called <this> at this other point in time."


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 23 22:40:42 2006

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