On 2008-04-10 11:05:07 -0400, Avery Pennarun wrote: > On Thu, Apr 10, 2008 at 4:41 AM, Karl Hasselström <kha@xxxxxxxxxxx> wrote: > > > The @rev is called a "peg revision", and is different from the > > "operative revision" specified with the -r flag. The peg revision > > is used in conjunction with a path to specify the file (or > > directory) you want, and the operative revision is used to specify > > which revision of that file you mean. > > Yes, but I believe you get the one from @rev if you don't specify > -r. > > For example, I can ask for an "svn diff svn://blahblah@56 > svn://blahblah@59" and it'll feed it to me as expected. Ah, I didn't know that. But the URL I threw at you agrees: > Note that even when you don't explicitly supply a peg revision or > operative revision, they are still present. For your convenience, > the default peg revision is BASE for working copy items and HEAD for > repository URLs. And when no operative revision is provided, it > defaults to being the same revision as the peg revision. Clearly, I need to use Subversion more, and not fool around with git all the time. :-) > > (This complexity is needed because subversion has a concept of > > file identity.) > > File renames make diffing and merging complicated no matter whether > you track them or not. > > svn's tracking of file identity is additional, but doesn't increase > the (UI) complexity in the common case. At least with svn, a newbie > can even get real work done without even knowing about -r *or* > @notation. I don't quite agree with you here. Subversion stores extra state, and that state needs to be considered (in the general case) when predicting what Subversion will do. There are a large number of simple cases where the user doesn't have to care, as you say, but every so often there's a case that's not so simple, and in those cases I _really_ prefer git's data model to Subversion's. > Compare that to arbitrary differences in behaviour between > "git-fetch" vs "git-fetch a" vs "git-fetch a b", or the difference > between HEAD^ and HEAD~1 and HEAD@1. git is very powerful, but also > definitely more complex for beginners. Oh, I'm not arguing on that point. I like git because it's beutiful on the _inside_. -- Karl Hasselström, kha@xxxxxxxxxxx www.treskal.com/kalle -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html