On Thu, 2004-07-29 at 15:11, rickla1@cox.net wrote:
> That's find if branches are just used for projects, but we use
> branches to contain developer changes. This is preferred so commits
> can be made, others can view the branches, and backups occur.
"To contain developer changes?" How is that different than what I'm
talking about? You can easily give every developer a private branch in
Subversion -- just copy the trunk directory to a new branch directory,
make the developer work on the branch, then merge the branch back to the
trunk. A lot of teams do this, it's a common use pattern.
>
> File centric is the reality isn't it? When I have to go to a
> repository for purposes of finding an introduced regression, it's
> usually a file.
No, it's a *changeset* which causes or fixes a bug. Not a single file
revision or line of code. I mean, sure, yes, a line of code can cause a
bug -- but you need to stop thinking down at that level. It's not the
"subversion way" to think about per-file revisions!
When hunting a bug, you can just as easily do a 'binary search' on
global revison numbers (changeset numbers), just as you do on revisions
within a single RCS file.
Once you've determined that revision N caused or fixed the bug, you see
which branch that changeset was committed to, then look at logs (or
policies) and figure out where else that changeset was ported (and/or
still needs to be ported to.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 29 22:26:06 2004