> "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.
Yes we agree, that's what we do. IT's a matter of investigating history.
> > 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.)
I don't know any other way of putting this. I realize all of what you're
saying. But when debugging code, and I find a chunk changed in one file, a
way to quickly see when it changed is invaluable.
Maybe you're giving me a way to do that and I just am not seeing it. If I
binary search revisions, how is that done? You're saying I can diff revs 50
and 51 in a repository tree (for all branches/trunk etc) and see the changes
for all files, then pick out my foo.c and look at it? I've read the docs but
I can't see how to do it.
---------------------------------------------------------------------
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:45:39 2004