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
Received on Tue Sep 24 11:15:15 2002