You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Perry E. Metzger" <pe...@wasabisystems.com> on 2001/11/26 15:15:08 UTC
dos about revisions (was Re: manual nit)
Ben Collins-Sussman <su...@collab.net> writes:
> For example, in the above paragraph: it's kind weird to describe
> anything as being "marked as deleted in the repository." It reminds
> of the way a CVS repository moves things to the attic. Really, it
> should probably say something like, "will be removed from the head
> revision in the repository." (Of course, this means that the man
> page probably needs a 1-paragraph intro about what a svn 'revision'
> really is.)
As long as they're being mentioned, I must confess to being a bit
confused about svn revisions. I've been playing a bit and can't quite
figure out how to do some things I'm used to in CVS. For instance,
when I do an "svn log IDEAS" in the checked-out SVN repo, I expected
to see all the changes made to IDEAS, but instead I saw all changes
ever made to the repository (!?).
Similarly, in the CVS world, when a user is a bit screwed up I can ask
them "okay, read me the revision ID number in foo.c -- is it 1.29?" --
so far, I haven't been able to establish if there is any such thing in
subversion at all.
The documentation should probably be a bit clearer on both of these
points -- the FAQ for CVS users might want to go over both of them for
example.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
COM layer update
Posted by Bill Tutt <ra...@lyra.org>.
Just thought I'd let everybody know that my local copy of the COM layer
has successfully checked out the SVN repository! Hopefully sometime this
week I'll be able to finish up some testing stuff, and some code
rearranging I need to do and commit the stuff to the repository.
Yay!
Hope everybody in the US had a nice long vacation weekend,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dos about revisions (was Re: manual nit)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> "Perry E. Metzger" <pe...@wasabisystems.com> writes:
>
> > As long as they're being mentioned, I must confess to being a bit
> > confused about svn revisions. I've been playing a bit and can't quite
> > figure out how to do some things I'm used to in CVS. For instance,
> > when I do an "svn log IDEAS" in the checked-out SVN repo, I expected
> > to see all the changes made to IDEAS, but instead I saw all changes
> > ever made to the repository (!?).
>
> We turned off the behavior you expect, because the repository's
> undeltification is a bit.... slow.... right now. We're working on
> it. But normally, 'svn log foo.c' will work the way you expect.
Yup. Perry (or anyone else), if you'd like more detail, see this
comment in libsvn_repos/log.c:svn_repos_get_log():
/* ### Below, we discover changed paths if the user requested
them (i.e., "svn log -v" means `discover_changed_paths' will
be non-zero here), OR if we're filtering on paths, in which
case we use changed_paths to determine whether or not to even
invoke the log receiver on this log item.
Note that there is another, more efficient way to filter by
path. Instead of looking at every revision, and eliminating
those that didn't change any of the paths in question, you
start at `start', and grab the fs node for every path in
paths. Check the created rev field; if any of them equal
`start', include this log item. Then jump immediately to the
next highest/lowest created-rev field of any path in paths,
and do the same thing, until you jump to a rev that's beyond
`end'. Premature optimization right now, however.
*/
That "more efficient way" is probably still a premature optimization,
believe it or not. The only reason we disabled the current way right
now is because we're waiting for a chance to make some performance
improvements to the filesystem's undeltification, improvements which
are necessary for *many* things, not just good log behavior.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
more about revisions and such
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Ben Collins-Sussman <su...@collab.net> writes:
> > I might still want to be able to identify which revision and branch
> > a file originated on in a customer delivered set.
>
> Every node in the filesystem remembers the revision in which it was
> first created. Nodes have no idea what 'branch' they belong to, since
> branches and tags are ordinary directories. But if a file is copied
> to a branch or tag area, the copy-history is remembered.
>
> If running 'svn log foo.c' showed you the history of foo.c -- and
> traced all the way back to the first revision in which it was created,
> as well as the directory in which it originated... that's enough for
> your use-case, right?
Not really. Allow me to explain the motive. Someone who does not have
access to the repository is delivered a source tree. They can't type
"svn log". They are having problems. You want to ask them to
(essentially) give you a string which will identify the file version
they're looking at (i.e. "foo.c 1.29") or you want to give them a
string like that and ask them if the file is that version.
The path in the repository + the global revision number should be
unique though, yes? That would be sufficient. Presumably $REVISON$
will handle that.
By the way, although they are not necessarily useful from an internal
infrastructure point of view, having a syntax for referring to an
individual file's changes. They could be translated by the system into
the global revision numbers when they are referred to, but they make a
convenient shorthand.
"What happened between the last two changes of this file" is often
something you want to ask, but having to remember in a huge repository
that those were revision numbers 102385833 and 102386924 might get to
be a bit much to type. Remember that a project like NetBSD gets
hundreds of commits a day -- the revision numbers will get dazzling
and thus hard to type very fast.
If you are doing an
svn diff -r 102385833 -r 102386924 foo.c
it will be hard to see if you made a mistake.
Asking for "+101" and "+102"
svn diff -r +101 -r +102 foo.c
(that's an off-the-cuff invented syntax meaning "change 101 and 102
to foo.c numbering from the origin" and may suck) or even
svn diff -r -2 -r -1 foo.c
indicating the change just before the head and the change just before
that to this file would be cool things. (-0 could mean the head, +0
the origin -- though again, this might suck.) Presumably subversion
wouldn't grok that internally but the tools could know you were
referring to that particular file's history.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dos about revisions (was Re: manual nit)
Posted by Ben Collins-Sussman <su...@collab.net>.
"Perry E. Metzger" <pe...@wasabisystems.com> writes:
> It notes that there is no such thing as a revision for an individual
> file. It says nothing about the equivalent of RCS keywords like
> $Id$.
As Mike said, keyword expansions are forthcoming.
> I might still want to be able to identify which revision and branch
> a file originated on in a customer delivered set.
Every node in the filesystem remembers the revision in which it was
first created. Nodes have no idea what 'branch' they belong to, since
branches and tags are ordinary directories. But if a file is copied
to a branch or tag area, the copy-history is remembered.
If running 'svn log foo.c' showed you the history of foo.c -- and
traced all the way back to the first revision in which it was created,
as well as the directory in which it originated... that's enough for
your use-case, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dos about revisions (was Re: manual nit)
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Ben Collins-Sussman <su...@collab.net> writes:
> > Similarly, in the CVS world, when a user is a bit screwed up I can ask
> > them "okay, read me the revision ID number in foo.c -- is it 1.29?" --
> > so far, I haven't been able to establish if there is any such thing in
> > subversion at all.
> >
> > The documentation should probably be a bit clearer on both of these
> > points -- the FAQ for CVS users might want to go over both of them for
> > example.
>
> Um, have you read the document "SVN for CVS Users". It's the very
> first topic covered! :-)
It notes that there is no such thing as a revision for an individual
file. It says nothing about the equivalent of RCS keywords like
$Id$. I might still want to be able to identify which revision and
branch a file originated on in a customer delivered set.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dos about revisions (was Re: manual nit)
Posted by Ben Collins-Sussman <su...@collab.net>.
"Perry E. Metzger" <pe...@wasabisystems.com> writes:
> As long as they're being mentioned, I must confess to being a bit
> confused about svn revisions. I've been playing a bit and can't quite
> figure out how to do some things I'm used to in CVS. For instance,
> when I do an "svn log IDEAS" in the checked-out SVN repo, I expected
> to see all the changes made to IDEAS, but instead I saw all changes
> ever made to the repository (!?).
We turned off the behavior you expect, because the repository's
undeltification is a bit.... slow.... right now. We're working on
it. But normally, 'svn log foo.c' will work the way you expect.
> Similarly, in the CVS world, when a user is a bit screwed up I can ask
> them "okay, read me the revision ID number in foo.c -- is it 1.29?" --
> so far, I haven't been able to establish if there is any such thing in
> subversion at all.
>
> The documentation should probably be a bit clearer on both of these
> points -- the FAQ for CVS users might want to go over both of them for
> example.
Um, have you read the document "SVN for CVS Users". It's the very
first topic covered! :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dos about revisions (was Re: manual nit)
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
cmpilato@collab.net writes:
> -- If you're talking about the $REVISION$ keyword substitution, it
> is planned for Subversion, but we're not there yet.
Ah, okay. Something on this being a planned but not yet implemented
feature would be nice in the documents.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dos about revisions (was Re: manual nit)
Posted by cm...@collab.net.
"Perry E. Metzger" <pe...@wasabisystems.com> writes:
> As long as they're being mentioned, I must confess to being a bit
> confused about svn revisions. I've been playing a bit and can't quite
> figure out how to do some things I'm used to in CVS. For instance,
> when I do an "svn log IDEAS" in the checked-out SVN repo, I expected
> to see all the changes made to IDEAS, but instead I saw all changes
> ever made to the repository (!?).
This is a temporary situation. The correct behavior for svn log is to
only show the revisions in which IDEAS changed. However, we have
temporarily disabled the server's ability to pay attention to any of
the paths passed to 'svn log' while we work out some optimization
issues.
> Similarly, in the CVS world, when a user is a bit screwed up I can ask
> them "okay, read me the revision ID number in foo.c -- is it 1.29?" --
> so far, I haven't been able to establish if there is any such thing in
> subversion at all.
Not sure what you mean when you are asking someone to "read you the
revision ID number in foo.c"
-- do you mean for them to run 'cvs status' and see what revision
foo.c is currently at in their working copy? If so, 'svn status
-v' is what you're looking for.
-- If you're talking about the $REVISION$ keyword substitution, it
is planned for Subversion, but we're not there yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org