You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Shawn Harrison <ha...@tbc.net> on 2005/01/05 01:17:07 UTC
Re: svn log hides log messages
The following was posted to users, but my question seems more like a
dev@ issue.
Ben Collins-Sussman wrote [01/04/05 6:33 PM]:
>> I assumed [ass outta you and me] the reason the `log` command held back
>> the new revision info was that the working copy didn't have the required
>> metadata until and `update` command was issued.
>>
>>
>
> (Everytime I explain this on the list, I swear under my breath that
> there's no FAQ for this in the book or website. But now there's a
> possibility the behavior may change, so I'm not going to write the FAQ.
> Instead, I'm going to repeat it all again, because I'm too lazy to look
> up my last explanation in the mail archives. :-) )
>
> If you have a working copy at r5, then 'svn commit foo.c', then foo.c is
> at r6, everything else still at r5. We've already established that.
>
> When you run 'svn log' with no arguments, it assumes a target of '.'
> just like every other command -- that is, that the 'target' of the
> command is the parent directory of foo.c. You're asking the server to
> "tell me all commits that ever happened to (or within) the parent
> directory." And because no peg-revision was specified, it assumes you
> want to know all commits that ever affected the parent directory *at its
> base revision*, which is 5. So the server happily digs up revision 5
> of the parent directory, and starts searching backwards through
> commits: r5, r4, r3, r2... and so on, sending only commit logs that
> affected that directory.
>
> If you had run 'svn update' first, to bring the entire working copy to
> r6, then 'svn log' would ask for the history of '.' at r6, and therefore
> you would see the commit you just made to foo.c.
>
I understand that the reason "svn log ." doesn't show the just-completed
change is so that svn log works like everything else, on the current
revision of the directory. Okay.
To my thinking, the version number of the directory itself should be the
same as the latest version of any file within it. When foo.c is
committed, there is also an implicit change to the parent dir (namely,
what it contains). So the parent dir should also have the later revision
number, all the way back up the parent hierarchy.
This behavior seems to me to be the complement of "svn ci .", in which
the directory is brought to a new revision as well as all modified files
within it.
Anyway, I'd be interested to know why what I've described is _not_ what
happens, because no doubt there's a very good design reason.
Thanks,
Shawn Harrison
--
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Dominic Anello <da...@danky.com>.
On 2005-01-05 14:21:23 -0600, Shawn Harrison wrote:
----8<----
> 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?
I might be able to clarify this. Say your repository history looks
something like this:
r1
A /trunk
A /trunk/foo
A /trunk/bar
r2
A /branch (from /trunk:1)
r3
M /branch/foo
r4
M /trunk/foo
M /trunk/bar
r5
D /trunk/foo
r6
A /trunk/foo (from /branch/foo:3)
Now, say your WC is /trunk at r4 and you are modifying bar. When you
commit, you get a mixed WC of /trunk and /trunk/foo at r4 and /trunk/bar
at r7.
If you were to do an 'svn log foo' in your WC and log defaulted to
HEAD, you'd see r6, r3, r2, r1
Instead, the current scheme uses BASE, so you see: r4, r1
Notice that these two sets are disjoint after r1 because they are
following different lines of development. Using HEAD in this instance
would be misleading, because it wouldn't be showing you the history of
the file you actually have on disk. Using HEAD shows you the history of
the file you would get if you chose to update.
I hope this helped clarify things. I myself struggled with the BASE vs
HEAD issue at first, but in time I've come to appreciate it.
-Dominic
Re: svn log hides log messages
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> I'm not sure why maxb's argument is such a big deal. We already have
> a strategy for the scenario he describes -- we use it already in all
> of our history-tracing peg-rev stuff in svn 1.1.
>
> For example, if I run 'svn cat -r 50 foo.c@HEAD', we're already
> checking that foo.c in HEAD is the same object as foo.c in r50. If
> not, we throw an error. I don't see why 'svn log' couldn't do the
> same sanity check.
I think maxb proposed exactly that, in fact...
Want to file the issue, then? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 5, 2005, at 2:34 PM, kfogel@collab.net wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>> Well, you've just presented one side of the debate that's been going
>> on forever on this list. The other side of the debate is:
>>
>> "If no target is given, then all svn subcommands default to operating
>> on '.' at its BASE revision." It's a consistency argument.
>
> Actually, as far as I know, no one is seriously making the consistency
> argument. People are making *other* arguments why we should keep it
> the way it is, for correctness reasons (see maxb's post, for example).
>
I'm not sure why maxb's argument is such a big deal. We already have a
strategy for the scenario he describes -- we use it already in all of
our history-tracing peg-rev stuff in svn 1.1.
For example, if I run 'svn cat -r 50 foo.c@HEAD', we're already
checking that foo.c in HEAD is the same object as foo.c in r50. If
not, we throw an error. I don't see why 'svn log' couldn't do the same
sanity check.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Well, you've just presented one side of the debate that's been going
> on forever on this list. The other side of the debate is:
>
> "If no target is given, then all svn subcommands default to operating
> on '.' at its BASE revision." It's a consistency argument.
Actually, as far as I know, no one is seriously making the consistency
argument. People are making *other* arguments why we should keep it
the way it is, for correctness reasons (see maxb's post, for example).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Shawn Harrison <ha...@tbc.net>.
Ben Collins-Sussman wrote [01/05/05 2:27 PM]:
>
> Well, you've just presented one side of the debate that's been going on
> forever on this list. The other side of the debate is:
> "If no target is given, then all svn subcommands default to operating on
> '.' at its BASE revision." It's a consistency argument.
> See the thread started by kfogel on this last week.
Yes, I have, thanks.
(In response to Karl's last post):
It sounds to me like you guys are trying to find a way to make it work
and still thinking through all the implications.
Thanks for listening, and for these excellent tools.
--
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 5, 2005, at 2:21 PM, Shawn Harrison wrote:
>
> 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.
>
Well, you've just presented one side of the debate that's been going on
forever on this list. The other side of the debate is:
"If no target is given, then all svn subcommands default to operating
on '.' at its BASE revision." It's a consistency argument.
See the thread started by kfogel on this last week.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Shawn Harrison <ha...@tbc.net>.
Shawn Harrison wrote [01/05/05 2:21 PM]:
> This would solve the vast majority of use cases.
>
That last comment was over-the-top coming from me. Sorry about that. I
guess I meant, "Sounds good to me."
--
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Shawn Harrison <ha...@tbc.net>.
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.
Shawn Harrison
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Max Bowsher <ma...@ukf.net>.
Ben Collins-Sussman wrote:
> On Jan 5, 2005, at 6:28 AM, Simon Comeau Martel wrote:
>
>>> 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 if you have a working copy at r5 and your commit r6, (ie: a bump of
>> exacly 1), wouldn't it be safe to assume that your entire working copy
>> is at r6, without an update?
>>
>
> Absolutely. But this is an incredibly rare and contrived case. Most
> of the time, you have a working copy made out of many mixed revisions,
> and 'svn commit' creates a new HEAD revision that is more than 1
> greater than the greatest revnum in the working copy. If you'd like to
> write optimization code for this teeny-tiny edge-case, it's certainly
> doable. I doubt it will make much difference.
... and we might well deem the extra complexity of an unnecessary edge case
to be a greater burden to maintainability than it is a benefit.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 5, 2005, at 6:28 AM, Simon Comeau Martel wrote:
>> 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 if you have a working copy at r5 and your commit r6, (ie: a bump of
> exacly 1), wouldn't it be safe to assume that your entire working copy
> is at r6, without an update?
>
Absolutely. But this is an incredibly rare and contrived case. Most
of the time, you have a working copy made out of many mixed revisions,
and 'svn commit' creates a new HEAD revision that is more than 1
greater than the greatest revnum in the working copy. If you'd like to
write optimization code for this teeny-tiny edge-case, it's certainly
doable. I doubt it will make much difference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Simon Comeau Martel <ma...@videotron.ca>.
> 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 if you have a working copy at r5 and your commit r6, (ie: a bump of
exacly 1), wouldn't it be safe to assume that your entire working copy
is at r6, without an update?
--
Simon Comeau Martel
martelsc@videotron.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 4, 2005, at 7:26 PM, Jim Correia wrote:
> On Jan 4, 2005, at 8:17 PM, Shawn Harrison wrote:
>
>> To my thinking, the version number of the directory itself should be
>> the same as the latest version of any file within it. When foo.c is
>> committed, there is also an implicit change to the parent dir
>> (namely, what it contains). So the parent dir should also have the
>> later revision number, all the way back up the parent hierarchy.
>
> 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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Jim Correia <ji...@pobox.com>.
On Jan 4, 2005, at 8:17 PM, Shawn Harrison wrote:
> To my thinking, the version number of the directory itself should be
> the same as the latest version of any file within it. When foo.c is
> committed, there is also an implicit change to the parent dir (namely,
> what it contains). So the parent dir should also have the later
> revision number, all the way back up the parent hierarchy.
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.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org