Ben Collins-Sussman wrote [01/04/05 10:49 PM]:
> On Jan 4, 2005, at 7:26 PM, Jim Correia wrote:
>> The directory is a separately versioned object (with its own
>> properties, etc). You can't arbitrarily decide to call what you have
>> N+1 just because one of its children was committed.
> Exactly. In Subversion's universe, "revision N of a directory" means 1)
> a specific list of child entries, and 2) a specific list of
> properties. As Jim said, you can't arbitrarily bump the working
> revision of a directory in a working copy just because you feel like
> it: you actually have to *have* the version of the directory.
Okay, that makes sense. I understand that this is how svn defines a
directory, and I understand that I don't necessarily have the latest
version when committing a new file or a changed file. (Sorry, Jim, that
I didn't understand right away.)
> So the classic example is:
> Say you have a working copy at r5, and commit foo.c, which creates r9.
> Certainly it's safe for the working copy to assume that its foo.c is at
> r9. But it's not safe to assume that the parent directory is at r9:
> what if somebody added or removed entries from the directory somewhere
> in r6, r7, or r8? What if somebody changed the directory's properties?
> Until you run 'svn up', it's not safe to assume that the working copy
> really has r9 of of the directory.
But svn log uses the repository, not the working copy, to get the log
for the directory. So why not use the HEAD of the directory in the
repository itself rather than the latest version of the working copy? In
general, why use the working copy as the point of reference for an
operation that accesses the repository? It would seem to be more
informative to see what has happened in the _repository_ after I last
did svn up, not just in the wc. I already know what's happened in the wc.
Max Bowsher wrote elsewhere:
> I'm -1 on just flipping the default to HEAD, since it would be
> horribly bizarre to see a different line of history being logged, if
> the name log is invoked on has been deleted and then
> replaced-with-history in HEAD, whilst your your WC is still on the
> previous historical line.
I'm afraid I don't understand this. How are there different "lines of
history" within a single branch of the repository?
> +0.5 on log doing a relatedness check between URL@HEAD and URL@BASE,
> and logging HEAD:0 if the test passes.
This would solve the vast majority of use cases.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jan 5 21:21:12 2005