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

Re: looking for one word to encompass trunk, tag and branch

From: Michael Rohan <mrohan_at_stonepillar.com>
Date: Tue, 18 Aug 2009 09:04:43 -0700

Hi Folks,

Given the layout in Subversion, perhaps, calling them "meta-directories"
would work.

Take care,

On Tue, Aug 18, 2009 at 8:53 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:

> B. Smith-Mannschott wrote:
> > On Tue, Aug 18, 2009 at 16:51, Les Mikesell<lesmikesell_at_gmail.com>
> wrote:
> >> They are all revisions... Tags are the only things that are different,
> and
> >> only by the convention that you don't commit after creating them so they
> >> only have the HEAD revision - and that isn't enforced.
> >
> > No, in the vocabulary of Subversion a "revision" is one of the
> > numbered transactions that make up the global history of a repository.
> > I have no desire to overload that term with an unrelated meaning.
> But they are all numbered transactions. There is no way to get anything
> else out of the repository. Perhaps the fact that the latest (head)
> transaction is conveniently used as the default if you don't supply one
> is confusing you. But find it's number and ask with/without and you'll
> see that you get the same thing.
> > A branch is not a revision. Nor a tag. Nor a trunk.
> The only thing you can reference with them is a revision. They exist
> only to hold revisions.
> > A branch may have
> > *been created* as part of a particular revision, when it was copied
> > form some-path last modified as part of some-other-revision. The
> > branch may even be said to have *been modified* as part of
> > this-revision and that-revision; last modified in another-revision.
> Try to describe how you get something other than a revision out. Or how
> committing creates something other than a revision. If you can, I've
> been missing something. (I suppose there are the non-versioned
> properties, but that's pretty esoteric.)
> > In our case "Version" and "revision" are both too overloaded for this
> > task. Version, in our usage, generally indicates a SCM version, like
> > 1.2.3 or 5.0.0-SNAPSHOT. We use Revision exclusively to describe
> > ordered commits to an Subversion repository.
> There's an elegant simplicity here. It's revisions all the way down.
> > Also, if we decided to call this a "revision" (url):
> >
> > svn://example.com/svn/repo/project/branches/new-hotness
> >
> > Then, what might we call this:
> >
> > svn://example.com/svn/repo/project/branches/new-hotness_at_r1111
> >
> > A revision revision? The "revision" new-hotness at revision 1111?
> Note that if your repository is at revision 1111 or there is nothing
> newer on that path, both of those refer to exactly the same thing.
> > As an aside, your mention of "HEAD" reminded me of something. In the
> > Mercurial world the term that I'm groping for would be "head". In
> > mercurial a head is a commit with no children, so it's the most recent
> > commit on some branch/tag/trunk. The mercurial people use the word
> > "tip" to describe the most recent head. (Roughly equivalent to
> > Subversion's use of HEAD).
> I think that's the elusive concept here. If you don't specify a
> revision explicitly you still get a revision that happens to be the
> HEAD. That doesn't mean it deserves another name. It's just a revision
> that, after the next commit, will require an explicit number to reproduce.
> --
> Les Mikesell
> lesmikesell_at_gmail.com
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2384817
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subversion.tigris.org].

Michael Rohan
Stone Pillar Technologies
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-18 18:05:38 CEST

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

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