Re: Can someone enlighten me?

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