[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RedHat 7.[23] RPMS for Subversion

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-06-19 23:31:03 CEST

Josef Wolf <jw@raven.inka.de> writes:

> > It's funny really.... when Jim Blandy designed this system, he was
> > hoping that we could eventually do away with the terms "branch" and
> > "tag" altogether. In Subversion, we only have a single idea:
> > "copies". The only reason we keep talking about branches and tags is
> > because we're trying to get CVS users to understand how to make SVN do
> > what they're used to.
>
> You confused me. How can you make a bugfix to 0.12.0 (or r1868, if you
> like) without the use of "tag" and "branch" directories?

We make a bugfix by:

   * copying (r1868, /trunk) to some new path.
   * apply the fix to the new path
   * roll a tarball from the new path.

The "new path" might be /branches/0.12.0, or it might be
/aoeu3/e37e98. It really doesn't matter, whatever is easiest for us.
Also, it's our right to decide if we want to delete the new path right
away, or if we want to keep it around as a parallel line of
development (i.e. keep applying bugfixes to it.) Also, at any time,
we have the option of creating /tags/0.12.0 as a copy of (r1868,
/trunk), just so we don't have to remember exactly where 0.12.0 is.
It's like a convenient bookmark, if we wish. But not required.

(However, for the subversion project, we happen to be remembering
where releases are by notating each revision/path in our CHANGES file.
And we don't have any parallel development branches open now, except
for the r2092 branch.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 19 23:33:00 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.