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
