On Fri, 2006-11-17 at 07:26 -0700, John Waycott wrote:
> Phyrefly wrote:
> > (forgot to reply all, again - Fwd-ed)
> >
> > This is starting to sound like an argument for not using source
> > revisioning at all.
> >
> > "If the developer doesn't comment a revision, we'll never know why
he
> > made that change"
> >
> > Hell, let's all pack it in, and never write another line of code,
just
> > in case someone creates a bug, or someone uses the application to do
> > something we didn't intend.
> >
> > <Serious mode on>
> > The alternative to "frankentags" is to checkout different versions
of
> > different things, and commit them all as one revision, tag that,
then
> > get the original HEAD code and re-commit it over the top. How is
that
> > more useful? Surely this contains _less_ information, as we don't
> > even know what revision that tagged code came from, much less why!
> >
> The alternative is to use branches as change sets and merge from the
> branches to get the features and fixes you need for a release. I don't
> like committing changes directly on the trunk (which is what complex
> tags encourages).
>
> The bookkeeping for complex tags breaks down when you have to perform
> multiple commits for a single change. For example, I fix bug A,
commit,
> then add feature X and commit. Now, I find the fix to bug A still has
an
> issue. So, I make more changes and commit. With complex tags, I would
be
> unable to easily select only the bug A fix for a release; I would have
> to check out the latest fix and then reverse delta the feature X
change.
> I also no longer have a way to easily tell what changes were made to
fix
> bug A.
This implies that you use one branch for every new feature (you could
also use one branch for multiple features) and a branch for bugfixes
which makes it easy to merge features and bugfixes easily between
branches.
A good approach in my opinion, but it really depends on the development
process and how "big" (or how long they depend to develop) new features
are. Meaning: when opening a new branch for a feature? when it takes 2
days to develop it? A week? A month? This decision has to be made
somehow and of course accordingly to the piece of software the team is
writing.
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 20 12:50:22 2006