[geeks] Subversion trunk and branch methods

[Charles Shannon Hendrix]

Wed, 16 Aug 2006 @ 02:30 -0400, der Mouse said:

> Not knowing anything about how subversion manages things, the first
> thing that occurs to me is to ask which is more important: manipulating
> the trunk for all projects, or manipulating the trunk and all branches
> for a particular project?

Turns out <project>/<dir> works out a lot better.  I thought at first
there might be something about subversion that made <dir>/<project>
better, but that's not true.

In fact, I can't see a logical reason to ever do <dir>/<project>.  It
might depend on how your work is structured.

> At least that is, as I said, the first reaction I have, without knowing
> anything of subversion's internals.  It may well be total gibberish.

No, those were good ideas.  However, you'll find out after usinb
subversion awhile that things aren't what they seem at first.  It's
really hard to fully describe something like that anyway.

> Only if you insist on reading "version N" as implying "N changes have
> occurred".  

No, but I do find value in knowing how many revisions have been done on
a project or a file.  With subversion you have to run a log command and
manually count the relevant changes, or script it.

I guess really what I'd like to see is a project revision number and a
file revision number just for reference.

Personally, I find that useful information.  Your mileage may vary.

> I version much of my software with version numbers like 20060722; are
> you unable to see this as meaning anything other than my having had
> over twenty million revs of that piece of software?

No, it's nothing like that at all.

> > Yes, the number applies to the entire repository, but then you have
> > to ask, what happened to the other 790 revisions of proj1?
> 
> What happened to the other 20,060,721 revs of my program?

I'd never ask that becuase that's *YOUR* version number.

> Not that I think subversion's rev style is perfect; I haven't thought
> about it enough to hold an informed opinion.  But I do think the svn
> developers are at least partially right in their response as you
> reported it.

The reason they response like that is because they don't have the
feature, even though a lot of people want it.  It's a rationalization of
a design decision that doesn't suit everyone.

I get what I want other ways in the end, and I'm ultimately willing to
forget about it to get the other benefits.

-- 
shannon "AT" widomaker.com -- [4649 5920 4320 204e 4452 5420 5348 5920 4820
2056 2054 434d 2048 4d54 2045 204e 5259 4820 444e 0a53]