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 <ghudson@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
Received on Tue Sep 24 17:46:36 2002