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

Re: Adding changeset-like functionality to subversion

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-10-08 22:11:35 CEST

Noel Yap <yap_noel@yahoo.com> writes:

> From my scant understanding of subversion (and please
> correct me if I'm wrong), subversion will version the
> entire tree with each commit, so, assuming the set of
> files within a commit operation comprises the change
> set, the change set will be whatever is different
> between one version of the tree and the next.

Correct.

> Again, from what little I understand of subversion,
> when that branch gets merged into main development,
> the entire tree will be versioned (on the main branch)
> and so, the change set will still be the difference
> between one version of the tree and the next.

I think so, yes.

"Dr. David Alan Gilbert" <sv@treblig.org> writes:

> * Ben Collins-Sussman (sussman@collab.net) wrote:
> >
> > Subversion has changesets, but they're sort of implicit. Each
> > subversion commit *does* have a unique name -- the revision number.
> > We can examine subversion's "changesets" by looking at the diff
> > between any two revisions. We can also apply a "changeset N" to a
> > working copy in any order by running 'svn merge -r N-1:N'.
>
> This has two potential problems. The first is that I may be working
> on a branch and doing various checkins before I wish to release the
> finished entire set as one 'changeset' in its entirity.

You can do as many commits on the branch as you wish. Each commit
creates a new global revision number, but that's not a big deal. When
the time comes to merge the branch into the trunk, you would simply
include the range of revisions that you created on the branch:

    svn merge -rX:Y http://my/branch .

> What I think people are looking for from changesets is a URL that
> you can give to someone who is managing a release and say
> 'my fix for the splurge bug is in http://myrepository/mychangeset...'
> and then the release person (or whoever wants to try it) can do
> svn magic http://myrepository/mychangeset

What we do now is say, "the fix for the spurge bug is revision 388.
That change happened on a branch, you'll see, if you look at its log.
Merge it into trunk if you want it."

Helpful hint -- for people who are new to this list, or to subversion:
I recommend reading our Design document. It's a bit out-of-date
(written over 2 years ago), but there's a nice section that
demonstrates the schema of the repository. It has examples, and
explains how branches and tags work. (If you didn't know already,
branches and tags are ordinary directories.)

Here's the link to the relevant section:

http://subversion.tigris.org/files/documents/15/17/svn-design.html#Repository%20Structure

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 8 22:13:33 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.