OK, so your explanation makes sense, thanks.
But given that, I still don't see how I could ever get svn log -r
COMMITTED to not give me a result at all, on any directory. When I saw
that happen, it was a more complicated scenario, involving wholesale
"svn move"s all over our repository, and I was getting this result after
a clean checkout. Was that a bug of some sort, or are there cases where
I could get nothing back from the svn log -r COMMITTED command?
And if you don't mind answering a "why are things this way" question, is
there a reason that there is no "local" analog to HEAD (e.g. find me the
latest in the repository that included a path at this directory or
underneath)? As far as I can tell, HEAD is global, and COMMITTED is
always underneath the current directrory. Is this correct?
Blair Zajac wrote:
> On Feb 8, 2006, at 10:32 PM, Lawrence Bruhmuller wrote:
>> So is this is a known issue? Should I report it through some other
>> means or will one of the developers pick this up?
>> Also (to anyone) would appreciate any insight to the other part of
>> my post, thanks in advance ...
>> - Lawrence
> It's not a bug.
> Directories have their own revision numbers, and just because you add
> a subdirectory, the containing directory does not have an implicit
> 'svn update' run on it, so it's still at revision 3. Remember,
> Subversion will not pull any updates down from the server to your
> client unless you request it, and this can include any changes on
> So in this example, the COMMITTED revision is 3 for the containing
> It goes to the same reason why you need to run 'svn update' in a
> directory after doing 'svn commit' to get the 'svn log' to show the
> I'm on a plane while writing this, but there's a section in the
> Subversion book that describes how directories are versioned. I
> would check that out.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Feb 12 06:32:04 2006