Looking back through the commits on the Java side of things I dont see anything too destabilizing going in, in fact more tests pass with this branch than did before including those tricky end-to-end tests. There were some particularly important performance optimizations that got picked up like the message bundle serialization. So while the process may have been messy the outcome is better for all concerned and we'll do better next time :)
On Sat, Dec 6, 2008 at 3:25 AM, Chris Chabot <[EMAIL PROTECTED]> wrote: > As being partially the reason for the re-branch, let me be the one to also > say: Ian's the one who volunteered to spend the time and effort taking care > of this for us, took the risk, and .. well we all learned how we could do > one thing better in the future, guess that happens when incubating :) > > I'm grateful to Ian that he's taking care of this for us! > > -- Chris > > On Sat, Dec 6, 2008 at 7:07 AM, Ian Boston <[EMAIL PROTECTED]> wrote: > > > The reason for the re-branch was a large re-factor in the php code base > to > > unify code style. Commit 719967 on 23 Nov *after* the previous branch was > > taken. It has been reported that patching over this commit is almost > > impossible. > > > > The branch was taken when it was to ensure that none off the 0.9 work got > > into the branch by mistake, and trunk was made free for 0.9 work. > > > > The previous branch was deleted to ensure that no one thought it was > active > > and they knew that there was a new branch (avoidance of confusion) > > > > Henning, > > I apologize if this caused you inconvenience, the intention to *rebranch* > > was announced and I assumed, that since you were concerned about the > trunk > > version number, you were Ok with the need to re-branch. > > > > If the 719967 commit had not happened, the branch would have simply been > > renamed. > > > > Ian > > > > > > On 5 Dec 2008, at 23:46, Adam Winer wrote: > > > > I don't know if there was more of a reason than the version change, but > I > >> strongly agree with Henning on principle here. A simple svn mv would > have > >> accomplished the rename. It's rare to need to delete SVN branches; > >> they're > >> very cheap. The sort of branch worth cleaning up is feature branches > that > >> have been merged. > >> On Fri, Dec 5, 2008 at 11:15 AM, Henning P. Schmiedehausen < > >> [EMAIL PROTECTED]> wrote: > >> > >> Hi, > >>> > >>> was it really necessary to branch off again? Why not just do > >>> > >>> svn move > >>> https://svn.apache.org/repos/asf/incubator/shindig/branches/0.8.1-x > >>> > >>> > https://svn.apache.org/repos/asf/incubator/shindig/branches/1.0.x-incubating > >>> > >>> ? > >>> > >>> People basing their work on the (promised) 0.8.1 release branch will > >>> now have to redo all their work against the new release branch, which > >>> branched off at an arbitrary point in time from the branch. Worse, all > >>> the changes on the release branch that were not in the trunk are now > >>> lost. > >>> > >>> Here is a hint: Between 0.8.1-x and 1.0.x-incubating, 616 files > >>> changed with a total of 6722 lines added and 8622 lines deleted. > >>> > >>> Even worse, someone deleted the old branch. Here is some advice for > >>> you: *NEVER* do that. There are people out there, tracking the SCM > >>> with other tools than svn. And for those people, you just broke their > >>> internal workflow. I am one of them. I am tracking (I used to track) > >>> 0.8.1-x with git-svn and our internal branch is (was) based on it. > >>> > >>> I e.g. now have to a) rebase all our work against trunk and b) making > >>> sure that the > 15,000 lines of changed code don't affect our work and > >>> c) must make sure that no post-0.8.1 code that has already bled into > >>> the trunk (opensocial templates) won't affect our release. Or I can > >>> just say "damn, I don't care", treat Shindig as a black box and hope > >>> for the best. > >>> > >>> Doing this and especially deleting the old branch might make sense in > >>> a controlled in-house environment where you can send out mail to all > >>> participants. Doing it in the open for an explicitly experimental > >>> marked branch is already bad. But doing this for a branch that was > >>> explicitly slated to be a release branch is, to be blunt here, a dumb > >>> thing. > >>> > >>> Ciao > >>> Henning > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Henning P. Schmiedehausen - Palo Alto, California, U.S.A. > >>> [EMAIL PROTECTED] "We're Germans and we use Unix. > >>> [EMAIL PROTECTED] That's a combination of two demographic > >>> groups > >>> known to have no sense of humour whatsoever." > >>> -- Hanno Mueller, > de.comp.os.unix.programming > >>> > >>> > > >
