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. 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.
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.
- 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.
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.
- 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.
- 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.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
