You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Roberto Nucera <nu...@gmail.com> on 2005/03/29 19:37:56 UTC
Help with Revision Numbers
Can anyone explain to me what a "working-revision" is? We are new to Subversion.
This is the example from the book (on svn status)
$ svn status --show-updates --verbose
M * 44 23 sally README
M 44 20 harry bar.c
* 44 35 harry stuff/trout.c
D 44 19 ira stuff/fish.c
A 0 ? ? stuff/things/bloo.h
Status against revision: 46
1. How can the branch be at revision 44 while the highest revision for
a file is 35?
2. What is the working revision (44?)
3. What is the other revision (say 35 for file trout.c)?
4. How are they related?
5. What is the 46 below (Status against revision)? Which revision is that?
// --
Thanks in advance!
roberto
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Help with Revision Numbers
Posted by Toby Johnson <to...@etjohnson.us>.
Roberto Nucera wrote:
>Toby, Sean
>
>Thanks!!
>
>My final question...
>The document speaks of trees...? "Revision numbers apply to entire trees"
>
>What is a tree? For example is the entire repository the tree (repo =
>tree) or can there be somehow independent trees inside a repository.
>
>Toby, you say "trunk" and "branches" don't really fit our model of
>workflow, so we don't even use them.
>
>
Yes, the repository is the tree. A tree is just a handy metaphor. Your
repository and all of its version history can be thought of as a bunch
of trees planted in a row. The first tree is tree #0 and the last one is
the HEAD. Any time any part (or parts) of the tree changes, you get a
new tree. Most items will not change from one tree to the next. And any
given working copy can have multiple pieces from multiple trees within
it, until you "svn update".
My comment about trunk and branches not fitting our workflow is due to
the fact that we used to use VSS and had internal build and deployment
tools which required items to be in specific locations within the
repository. When we converted to Subversion, I left that structure
alone. The great thing about it is that Subversion doesn't even care. It
doesn't matter that I have no directory called "trunk" or "branches" or
"tags".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Help with Revision Numbers
Posted by Daniel Patterson <da...@danpat.net>.
Roberto Nucera wrote:
> Toby, Sean
>
> Thanks!!
>
> My final question...
> The document speaks of trees...? "Revision numbers apply to entire trees"
>
> What is a tree? For example is the entire repository the tree (repo =
> tree) or can there be somehow independent trees inside a repository.
I sense you're still a little confused :-)
Subversion does not assign version numbers to individual files.
The repository as a whole has a "revision number" which represents
the number of changes that have been made to that repository. Every
time a commit is made, that number goes up by one. There cannot
be independent trees that have different incrementing revision
numbers within a single repository. It simply doesn't work that
way.
To determine things like "how many times has this file changed",
you need to use "svn log" to view the history of that file,
and count the changes yourself. Subversion doesn't give you
a "version number" for any file or directory, it just reports the
"revision number" for the repository.
When you change any file, it causes a new revision of all its parents
to be created. For example, if I change "/a/b/c.txt", a new
revision of c.txt is created, along with a new revision of /a/b,
a new revision of /a and a new revision of / (the latter three
being directories).
This has the effect of ensuring that every time a change is made,
a new version of the "/" directory is updated. This is kind of
what Toby and Sean meant by "versions entire trees".
Because branches and tags are merely simulated within the repository
using copies, they share all the semantics described above.
For example, lets take a copy of the directory "/trunk" and
put it in "/branches/release_1_prep" at repository revision 45.
Now, we continue working on "/trunk", making another 15 changes,
this puts the "repository version" at 60. Note that no changes
have been made to "/branches/release_1_prep" yet.
Now, if I do a:
svn co url://repos/branches/release_1_prep
Subversion will print out:
U release_1_prep/a.txt
....
At revision 60
So, even though no changes were made to /branches/release_1_prep,
the "repository version" has still changed.
If you compare /branches/release_1_prep at revision 45 to
/branches/release_1_prep at revision 60, there will be no differences.
All the changes between repository version 45 and 60 were made
to /trunk.
Does that help?
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Help with Revision Numbers
Posted by Roberto Nucera <nu...@gmail.com>.
Toby, Sean
Thanks!!
My final question...
The document speaks of trees...? "Revision numbers apply to entire trees"
What is a tree? For example is the entire repository the tree (repo =
tree) or can there be somehow independent trees inside a repository.
Toby, you say "trunk" and "branches" don't really fit our model of
workflow, so we don't even use them.
Can you comment a bit on that?
Thanks again,
roberto
On Tue, 29 Mar 2005 23:00:30 -0500, Toby Johnson <to...@etjohnson.us> wrote:
> Roberto Nucera wrote:
>
> >And this is true, I did an svn update, but what could have caused this
> >branch to be at 44,
> >since all it's local revisions are less than 44?
> >
> >For you information, this is a "branch" not the trunk. Could it be
> >that the trunk is at 44? and so this branch also is at 44? Any other
> >reason as to why this could happen?
> >
> >
> Yes, that's exactly the case. There is only one current/most recent/HEAD
> revision number for the *entire repository*. If the repository is at
> revision n, and you commit changes to just one file, then *all files*
> are now at revision n+1, whether they are in the trunk, a branch, a tag,
> etc. Most of those files didn't change from revision n to n+1, but their
> revision number increased nonetheless.
>
> For what it's worth, Subversion places *no relevance whatsoever* on
> trunk vs. branches vs. labels. They're all just directories in the
> repository.. it's the people who use those different locations that
> attach the meaning to them. Once you wrap your head around that concept
> it's much easier to see how changes in the trunk can affect the revision
> numbers of branches. (In fact, at my company, "trunk" and "branches"
> don't really fit our model of workflow, so we don't even use them.)
>
> As Sean suggested, you should read up on the relevant sections on "SVN
> for CVS users" as well as the part explaining what revision numbers mean.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Help with Revision Numbers
Posted by Toby Johnson <to...@etjohnson.us>.
Roberto Nucera wrote:
>And this is true, I did an svn update, but what could have caused this
>branch to be at 44,
>since all it's local revisions are less than 44?
>
>For you information, this is a "branch" not the trunk. Could it be
>that the trunk is at 44? and so this branch also is at 44? Any other
>reason as to why this could happen?
>
>
Yes, that's exactly the case. There is only one current/most recent/HEAD
revision number for the *entire repository*. If the repository is at
revision n, and you commit changes to just one file, then *all files*
are now at revision n+1, whether they are in the trunk, a branch, a tag,
etc. Most of those files didn't change from revision n to n+1, but their
revision number increased nonetheless.
For what it's worth, Subversion places *no relevance whatsoever* on
trunk vs. branches vs. labels. They're all just directories in the
repository.. it's the people who use those different locations that
attach the meaning to them. Once you wrap your head around that concept
it's much easier to see how changes in the trunk can affect the revision
numbers of branches. (In fact, at my company, "trunk" and "branches"
don't really fit our model of workflow, so we don't even use them.)
As Sean suggested, you should read up on the relevant sections on "SVN
for CVS users" as well as the part explaining what revision numbers mean.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Help with Revision Numbers
Posted by Sean Laurent <se...@neuronfarm.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 29 March 2005 05:35 pm, Roberto Nucera wrote:
> It cannot be another person working on this branch, otherwise one of
> this files would also be at 44, correct?
It sounds like you're a former CVS user, correct? You probably want to read
Appendix A in the manual:
Appendix A: Subversion for CVS Users
http://svnbook.red-bean.com/en/1.1/apa.html
It talks about the differences in how Subversion handles revision numbers.
You may also want to read the section on revisions in Chapter 2:
http://svnbook.red-bean.com/en/1.1/ch02s03.html#svn-ch-2-sect-3.2
- -Sean
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCSesdzBEkVQQ0ejkRApQOAJwLEvr9/NFfGMvjpJPvI1kH4nmYEACff5kL
z7ezfzOVhXLhEX6w/yvio4c=
=OP4g
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Help with Revision Numbers
Posted by Roberto Nucera <nu...@gmail.com>.
Toby,
Thanks for the explanations. They helped a lot.
You mentioned that - All those "44"s in your printout indicate that
the "working revision" of
those files is 44. You must have either just checked out the WC, or
recently did an "svn update" to version 44."
And this is true, I did an svn update, but what could have caused this
branch to be at 44,
since all it's local revisions are less than 44?
For you information, this is a "branch" not the trunk. Could it be
that the trunk is at 44? and so this branch also is at 44? Any other
reason as to why this could happen?
It cannot be another person working on this branch, otherwise one of
this files would also be at 44, correct?
Thanks again
roberto
On Tue, 29 Mar 2005 15:48:35 -0500, Toby Johnson <to...@etjohnson.us> wrote:
> In Subversion, working copies (WC) can have their elements at different
> revision numbers. Some files might be at lower revision numbers, while
> others are at higher revision numbers.
>
> When you first check out a WC, all items are at the same revision number
> (usually HEAD unless you specified a different revision). As you make
> changes to individual files/directories, and commit those changes, then
> those particular files are at a newer revision than the rest of the WC.
> You can bring the entire WC up to the latest revision using "svn update".
>
> All those "44"s in your printout indicate that the "working revision" of
> those files is 44. You must have either just checked out the WC, or
> recently did an "svn update" to version 44.
>
> The "other" revision is the last-changed revision. For trout.c, even
> though its local copy has been updated to revision 44, the last time it
> was actually *changed* was back in revision 35. This duality exists
> because revision numbers are global, i.e. they pertain to the entire
> repository and not just one file. So even though your local copy of
> trout.c is at revision 44, it wasn't changed in revisions 36-44.
>
> The "Status against revision: 46" is due to the --show-updates, which
> checks for changes from the repository as well as local changes. This
> means that the repository is currently at revision 46 (its current
> HEAD). That means some files might have changed since you checked out or
> updated your WC (and indeed they have, as seen by the "*" on a couple
> files). If you were to run "svn update" at this point, all "working
> revisions" would be brought to 46, and the appropriate (remote) changes
> would be brought down locally.
>
> You can picture why a branch can be at a newer revision than some of its
> member files by remembering that branches are simply cheap copies. So if
> the branch took place at revision 35, and some (but not all) of its
> members were modified after that, then those members which haven't been
> modified at all can still be at revision 35 (at least until another "svn
> update" is made).
>
> Roberto Nucera wrote:
>
> >Can anyone explain to me what a "working-revision" is? We are new to Subversion.
> >
> >This is the example from the book (on svn status)
> >
> >$ svn status --show-updates --verbose
> > M * 44 23 sally README
> > M 44 20 harry bar.c
> > * 44 35 harry stuff/trout.c
> > D 44 19 ira stuff/fish.c
> > A 0 ? ? stuff/things/bloo.h
> >
> >Status against revision: 46
> >
> >1. How can the branch be at revision 44 while the highest revision for
> > a file is 35?
> >2. What is the working revision (44?)
> >3. What is the other revision (say 35 for file trout.c)?
> >4. How are they related?
> >5. What is the 46 below (Status against revision)? Which revision is that?
> >
> >// --
> >
> >Thanks in advance!
> >
> >roberto
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Help with Revision Numbers
Posted by Toby Johnson <to...@etjohnson.us>.
In Subversion, working copies (WC) can have their elements at different
revision numbers. Some files might be at lower revision numbers, while
others are at higher revision numbers.
When you first check out a WC, all items are at the same revision number
(usually HEAD unless you specified a different revision). As you make
changes to individual files/directories, and commit those changes, then
those particular files are at a newer revision than the rest of the WC.
You can bring the entire WC up to the latest revision using "svn update".
All those "44"s in your printout indicate that the "working revision" of
those files is 44. You must have either just checked out the WC, or
recently did an "svn update" to version 44.
The "other" revision is the last-changed revision. For trout.c, even
though its local copy has been updated to revision 44, the last time it
was actually *changed* was back in revision 35. This duality exists
because revision numbers are global, i.e. they pertain to the entire
repository and not just one file. So even though your local copy of
trout.c is at revision 44, it wasn't changed in revisions 36-44.
The "Status against revision: 46" is due to the --show-updates, which
checks for changes from the repository as well as local changes. This
means that the repository is currently at revision 46 (its current
HEAD). That means some files might have changed since you checked out or
updated your WC (and indeed they have, as seen by the "*" on a couple
files). If you were to run "svn update" at this point, all "working
revisions" would be brought to 46, and the appropriate (remote) changes
would be brought down locally.
You can picture why a branch can be at a newer revision than some of its
member files by remembering that branches are simply cheap copies. So if
the branch took place at revision 35, and some (but not all) of its
members were modified after that, then those members which haven't been
modified at all can still be at revision 35 (at least until another "svn
update" is made).
Roberto Nucera wrote:
>Can anyone explain to me what a "working-revision" is? We are new to Subversion.
>
>This is the example from the book (on svn status)
>
>$ svn status --show-updates --verbose
> M * 44 23 sally README
> M 44 20 harry bar.c
> * 44 35 harry stuff/trout.c
> D 44 19 ira stuff/fish.c
> A 0 ? ? stuff/things/bloo.h
>
>Status against revision: 46
>
>1. How can the branch be at revision 44 while the highest revision for
> a file is 35?
>2. What is the working revision (44?)
>3. What is the other revision (say 35 for file trout.c)?
>4. How are they related?
>5. What is the 46 below (Status against revision)? Which revision is that?
>
>// --
>
>Thanks in advance!
>
>roberto
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org