Can someone enlighten me?

[Kean Johnston <jk...@caldera.com>]

Good evening all,

I have been making my way slowly through the handbook (which
is very nicely written BTW) and something I read there had
me scratching me head as to why it was implemented this way.
I realize that you folks most probably thrashed this out
quite a while ago, and if this is covered in a mailthread
archive I can follow, that'd be great. What I'd like to
understand why a revision follows an entire tree and not
individual changes?

Consider this. Lets say theres a large project with 20
engineers working on it. Lets say, in a week, each of
the devlopers makes 10 changes. That means that every week
the revision of the tree is increasing by 200. In a team that
size its likely to be much much more, however. Since most
developers are not coming to version control for the first
time, this can be a problem. We can all reamember fairly
low numbers, but what happens after two or three years of
active development, especially where even the slightest
change results in an entire tree reversioning? It gets
difficult to remember that revision 386419 had the fix
to the bug that was introduced at revision 353816.

I'd really like to understand the thinking behind this
approach versus a more traditional approach of each
entity retaining its own unique revision identity and
then having tags be symbolic names that "look through"
a set of revisions and group the tree at a point in time
that makes sense to the developers using the tree. I know
this is not going to change in svn but I really would
like to understand why this is the case so that it can
become an instinctive way for me to look at a tree.

Thanks for any pointers or time taken to explain this.

Kean


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Can someone enlighten me?

[Timothee Besset <tt...@idsoftware.com>]

Well, just for the record I'd point out that even if SVN branches are
designed to work faster than CVS, treating them like any other
subdirectory and expecting the svn users and admins to follow an implicit
policy of trunk/ and branches/ layout may not be such a good thing.

Coming from CVS, I'm slowly making the switch to understand the branching
strategy of SVN. But even if my branches are listed physically in the
tree, I still need to have a tree-like view of my core source evolution to
know where I am.

For instance, branches created out of branches? Say I branch a 'Stable'
version of my source, like so:

trunk/
branches/Stable/

Now someone starts doing OSX porting work on the Stable branch. Do I do:

trunk/
branches/Stable/
branches/OSX/

That doesn't reflect the hierarchy correctly. What I would probably do:

trunk/
branches/Stable/
branches/Stable-branches/OSX/

or even
trunk/
branches/Stable/trunk/
branches/Stable/branches/OSX/
(which may be more rigorous, but obviously annoying to work with)

Just to point out that those things will require a good dose of user
practice.

TTimo

On 24 Sep 2002 11:15:44 -0400
Greg Hudson <gh...@MIT.EDU> wrote:

> On Tue, 2002-09-24 at 04:58, Kean Johnston wrote:
> > It gets
> > difficult to remember that revision 386419 had the fix
> > to the bug that was introduced at revision 353816.
> 
> One solution here is to learn to use branches and tags more--or, in
> Subversion speak, learn to use directory copies more.  CVS discourages
> branches and tags because:
> 
>   1. They're slow
> 
>   2. Once you've created a branch or tag, it clutters up the header of
> each file's log output forever.  (Unless you rewrite history by
> destroying the branch or tag.)
> 
> By contrast, Subversion makes directory copies fast, and also makes it
> just as fast an easy to delete a directory copy (without rewriting
> history) once you don't need it any more.  So you can maintain a current
> set of tags (copies) really easily.
> 
> So, instead of telling your coworkers that r386419 has the bug fix, tell
> them that /tags/fix-for-bug has the bug fix.  A simple "svn log
> /tags/fix-for-bug" will tell them the revision number which created that
> directory copy, if they really want it for some reason.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Can someone enlighten me?

[Greg Hudson <gh...@MIT.EDU>]

On Tue, 2002-09-24 at 04:58, Kean Johnston wrote:
> It gets
> difficult to remember that revision 386419 had the fix
> to the bug that was introduced at revision 353816.

One solution here is to learn to use branches and tags more--or, in
Subversion speak, learn to use directory copies more.  CVS discourages
branches and tags because:

  1. They're slow

  2. Once you've created a branch or tag, it clutters up the header of
each file's log output forever.  (Unless you rewrite history by
destroying the branch or tag.)

By contrast, Subversion makes directory copies fast, and also makes it
just as fast an easy to delete a directory copy (without rewriting
history) once you don't need it any more.  So you can maintain a current
set of tags (copies) really easily.

So, instead of telling your coworkers that r386419 has the bug fix, tell
them that /tags/fix-for-bug has the bug fix.  A simple "svn log
/tags/fix-for-bug" will tell them the revision number which created that
directory copy, if they really want it for some reason.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Can someone enlighten me?

[Ben Collins-Sussman <su...@collab.net>]

Julian Fitzell <ju...@beta4.com> writes:

> I'll let someone else handle the technical reasons but I'll throw in
> that I actually find one revision number simpler.
> 
> In CVS, I keep having to add bugnotes that say:
> 
> " Fixed in CVS foo.c:1.45, bar.c:1.234, baz/other.c:1.5 "
> 
> etc... which sucks.  With one revision number log messages you can
> atomically refer to one set of changes with one number.  Also one
> commit has one log message, which makes sense.  This way you can
> always undo all the changes associated with one commit - you don't
> have to look at log messages to tie together changes to various
> directories, get all the version numbers and apply the updates
> manually.  And you don't have to look up the date either.

Yes, a single number is definitely more convenient than a list of
numbers.  Each revision is just a name for some changeset, some
particular commit.  From a CVS point-of-view, it's as if the system
automatically created a tree-wide tag everytime somebody made a
commit.

Re: Can someone enlighten me?

[Rafael Garcia-Suarez <ra...@hexaflux.com>]

Julian Fitzell <ju...@beta4.com> wrote:
> I'll let someone else handle the technical reasons but I'll throw in 
> that I actually find one revision number simpler.
> 
> In CVS, I keep having to add bugnotes that say:
> 
> " Fixed in CVS foo.c:1.45, bar.c:1.234, baz/other.c:1.5 "
> 
> etc... which sucks.  With one revision number log messages you can 
> atomically refer to one set of changes with one number.  Also one commit 
> has one log message, which makes sense.  This way you can always undo 
> all the changes associated with one commit - you don't have to look at 
> log messages to tie together changes to various directories, get all the 
> version numbers and apply the updates manually.  And you don't have to 
> look up the date either.

Moreover you can refer to the source tree 'at revision #NNNN', which I find
quite convenient for checkouts and tarball snapshots.

> I do have a mild concern that it will get unwieldy after 5 or 10 years 
> when your revision numbers are huge but the r32xx numbers from 
> Subversion don't bother me at all so I have no real evidence to suggest 
> it will get worse.  The other thing is just to make sure each project 
> has it's own repository so the numbers don't get any bigger than necessary.

Perforce uses a similar incremented global revision number.

Perl 5 uses Perforce as its main source repository since 1997, and has reached
change #17914 -- including all changes in maintenance and architecture-specific
branches. Those numbers don't confuse people, and it's very useful to know,
for example, that change #NNNN introduced some bug, or that change #MMMM
corrected some other bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Can someone enlighten me?

[Julian Fitzell <ju...@beta4.com>]

I'll let someone else handle the technical reasons but I'll throw in 
that I actually find one revision number simpler.

In CVS, I keep having to add bugnotes that say:

" Fixed in CVS foo.c:1.45, bar.c:1.234, baz/other.c:1.5 "

etc... which sucks.  With one revision number log messages you can 
atomically refer to one set of changes with one number.  Also one commit 
has one log message, which makes sense.  This way you can always undo 
all the changes associated with one commit - you don't have to look at 
log messages to tie together changes to various directories, get all the 
version numbers and apply the updates manually.  And you don't have to 
look up the date either.

I do have a mild concern that it will get unwieldy after 5 or 10 years 
when your revision numbers are huge but the r32xx numbers from 
Subversion don't bother me at all so I have no real evidence to suggest 
it will get worse.  The other thing is just to make sure each project 
has it's own repository so the numbers don't get any bigger than necessary.

Julian

Kean Johnston wrote:
> Good evening all,
> 
> I have been making my way slowly through the handbook (which
> is very nicely written BTW) and something I read there had
> me scratching me head as to why it was implemented this way.
> I realize that you folks most probably thrashed this out
> quite a while ago, and if this is covered in a mailthread
> archive I can follow, that'd be great. What I'd like to
> understand why a revision follows an entire tree and not
> individual changes?
> 
> Consider this. Lets say theres a large project with 20
> engineers working on it. Lets say, in a week, each of
> the devlopers makes 10 changes. That means that every week
> the revision of the tree is increasing by 200. In a team that
> size its likely to be much much more, however. Since most
> developers are not coming to version control for the first
> time, this can be a problem. We can all reamember fairly
> low numbers, but what happens after two or three years of
> active development, especially where even the slightest
> change results in an entire tree reversioning? It gets
> difficult to remember that revision 386419 had the fix
> to the bug that was introduced at revision 353816.
> 
> I'd really like to understand the thinking behind this
> approach versus a more traditional approach of each
> entity retaining its own unique revision identity and
> then having tags be symbolic names that "look through"
> a set of revisions and group the tree at a point in time
> that makes sense to the developers using the tree. I know
> this is not going to change in svn but I really would
> like to understand why this is the case so that it can
> become an instinctive way for me to look at a tree.
> 
> Thanks for any pointers or time taken to explain this.
> 
> Kean
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 


-- 
julian@beta4.com
Beta4 Productions (http://www.beta4.com)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Can someone enlighten me?

[egor duda <de...@logos-m.ru>]

Hi!

Tuesday, 24 September, 2002 you wrote:

KJ> Consider this. Lets say theres a large project with 20
KJ> engineers working on it. Lets say, in a week, each of
KJ> the devlopers makes 10 changes. That means that every week
KJ> the revision of the tree is increasing by 200. In a team that
KJ> size its likely to be much much more, however. Since most
KJ> developers are not coming to version control for the first
KJ> time, this can be a problem. We can all reamember fairly
KJ> low numbers, but what happens after two or three years of
KJ> active development, especially where even the slightest
KJ> change results in an entire tree reversioning? It gets
KJ> difficult to remember that revision 386419 had the fix
KJ> to the bug that was introduced at revision 353816.

With the speed you're talking about, you'll reach revision 353816
after more than 30 years of development :)

If you're concerned about simplicity of revision numbers you may
bump revision number every year (or month, or week) to some nice value
like xxx000 by performing an appropriate quantity of "dummy" commits.

Or, in a more general way, i suppose it's possible to add an ability
to subversion to refer to revision in the form <symbolic_tag>+offset
Then you'll be able to talk about revision 386419 as revision
"release_10_2_18+135" where release_10_2_18 is a symbolic tag of
revision 386284.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org