In most projects the latest and greatest code is in the trunk, See
Subversion Red-Bean Book
<http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.commonpatterns>.
What Wes suggests is going to be the easiest to follow. Recall when all
those reverse merges are performed they are all performed in the working
copy which will then need to be committed. So it won't be clear whats
happening.
-Rob
On 11/21/2010 8:19 PM, Wes Wannemacher wrote:
Seems like a lot of work. Why not make a branch from the 2.2.1 tag?
-Wes
On 11/21/10, Lukasz Lenart<lukasz.len...@googlemail.com> wrote:
Hi,
I'm going to revert changes made to the trunk to keep it clean (as it
was after 2.2.1 release) and move the whole development to branches.
Why? To have trunk always ready to apply security patches and to make
a new release quite fast (vote and tests).
The problem is, the current trunk contains already many changes, so I
must revert all those changes. I've made two new branches -
STRUTS_RELEASE_2_2_2 (trunk with all the changes) and
STRUTS_RELEASE_2_2_1_1 (clean copy after 2.2.1 release). Right now I'm
going to rename the current trunk to something like TRUNK-DEPRECATED
and then rename STRUTS_RELEASE_2_2_1_1 to be a new trunk.
Or use that solution [1] to merge changes from the revision just after
2.2.1 release to trunk and continue development on
STRUTS_RELEASE_2_2_2. But I'm expecting many conflicts as merge will
remove some files and the changes form trunk that already in
STRUTS_RELEASE_2_2_2 and merging them back can be a huge paint in the
neck :P
What do you propose?
[1] http://aralbalkan.com/1381
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia 2010 http://javarsovia.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
