On May 13, 2009, at 12:55 PM, Ralph Goers wrote:
On May 13, 2009, at 10:41 AM, David Jencks wrote:
Sorry I wasn't more specific last night at 2:00 am :-). I need
more scm context to understand. I'm assuming something like svn with
+tags
+root-1.0 (1.0)
+A(1.0)
\B(1.0)
+root-1.1 (1.1)
+A(1.0)
\B(1.1)
\root-1.2 (1.1)
+A(1.0)
\B(1.2)
\trunk
\root(1.2-SNAPSHOT)
+A(???? 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???)
\B(1.3-SNAPSHOT)
I have several assumptions about releasing stuff...
Your assumptions are not completely correct.
a) In our case a release is aways off a branch. This isn't
particularly relevant to the discussion but it does make production
maintenance easier so I'll ignore it.
b) tagging doesn't create a copy of anything.
Maybe on the svn server that's true, but I'd never know it from the
client view I get by svn co, svn up, etc.
It just is a label that is a shortcut to a revision on a branch.
Multiple tags that point to the same revision are not a problem and
don't incur much overhead.
I really don't care how much trouble releasing stuff causes infra disc
purchase procedures :-)
So the tree really looks like:
+tags
+root-1.0 (trunk revision 1)
+A(1.0)
+B(1.0)
+root-1.1 (trunk revision 2)
+A(1.0)
+B(1.1)
+root-1.2 (trunk revision 3)
+A(1.0)
+B(1.2)
/trunk at revision 4
+root(1.2-SNAPSHOT)
+A(1.0)
+B(1.3-SNAPSHOT)
This assumes that A has not been modified since its initial release
and B is currently under development and has not been released.
So, we seem to have different views on acceptable ways to use svn. If
I was involved in such a project I would kick and scream until
- each release came from a single clearly identifiable scm location
(violated by multiple tags for A(1.0), and the presence of A(1.0) in
trunk)
- trunk contained only SNAPSHOT version (except possibly while someone
is actually doing a release -- behavior of the release plugin I'm not
thrilled with) (violated by A(1.0) in trunk).
or I gave up and forked it.
I could be completely misguided in this, but it's my current viewpoint.
- development will continue after the release
- therefore the version in "trunk" must be incremented so it's
clear that snapshots are later than the release
- tags should not contain anything with a snapshot version
- releasing will create a tag of what's been released
- tagging for release creates a copy of an entire svn subtree, not
a copy with stuff removed.
See above. While the tag applies to the whole subtree, no copy is
made.
From the point of view of what you get on a client machine, I don't
understand this.
I see several problems with the svn tree I sketched above:
- there are 3 or 4 copies of A claiming to be version 1.0
No. There are multiple tags that all point to the same subversion
revision. This is not a problem.
Apparently we disagree on this.
- there is no plausible version for trunk/root/A
? If A has not been changed its version is still 1.0. If it has then
it is 1.1-SNAPSHOT.
Again we disagree on whether this is acceptable.
- in tags, the version of root doesn't match the end of the
directory name. (there are 2 version 1.1 roots)
Why would you allow a branch that matches a tag? If I was going to
allow a branch to be created named root-1.2 then I would require
that all tags be named root-1.2.n. If I did that then I would have
+tags
+root-1.0.0 (trunk revision 1)
+A(1.0.0)
+B(1.0.0)
+root-1.1.0 (trunk revision 2)
+A(1.0.0)
+B(1.1.0)
+root-1.2.0 (root-1.2 revision 3)
+A(1.0.0)
+B(1.2.0)
/root-1.0 (branched from trunk at revision 1)
+A(1.0.0)
+B(1.0.0)
/root-1.1 (branched from trunk at revision 2)
+A(1.0.0)
+B(1.1.0)
/root-1.2 (branched from trunk at revision 3)
+A(1.0.0)
+B(1.2.0)
/trunk at revision 4
+root(1.2-SNAPSHOT)
+A(1.0)
+B(1.3-SNAPSHOT)
I must not be understanding something basic about what you are
proposing.... I'm probably beating a long-dead horse but could you
please be even more specific about what scm operations you want to
have as part of a release and what the scm repo looks like
afterwards?
I'm not proposing anything. I'm just explaining what this particular
project has been doing for the last 5 years and why Maven 2 is a
PITA in this regard. Maven 1 was actually easier for this particular
project.
This process may work fine for the project in question and you in
other circumstances, but would keep me from contributing no matter
what build tool was in use.
Here, the release plugin seems to me to strongly promote good scm
practices. The only think I'd like to see is, given a setup like
trunk (has no pom)
+parent-pom
+P1
+P2
....
+P1000
an easy way to release all the, say, odd numbered projects at once
rather than running the release plugin on each one independently.
Anyway, I really appreciate your taking the time to explain your point
of view to me. While I currently don't think this process is a good
idea, I'll keep it in mind and may eventually have a change of heart :-)
thanks
david jencks
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
