2010/1/14 Norman Maurer <[email protected]>: > Hi Markus, > > svn rm and svn mv are not a good way for doing this.. This will affect > history ...
if we do a merge then we'll keep trunk history (during the branch) but every revision done in the branch will be lost. If we do the rm+mv then we'll keep branch revisions but loose any change done in trunk during the branch. Given that we had no changes in trunk during the branch it seems that rm+mv is the best choice. Stefano > Bye, > Norman > > 2010/1/13 Markus Wiederkehr <[email protected]>: >> On Wed, Jan 13, 2010 at 6:42 PM, Stefano Bagnara <[email protected]> wrote: >>> 2010/1/8 Oleg Kalnichevski <[email protected]>: >>>> With so many classes moved to different packages an iterative merge >>>> would just be too hard. I am +1 to merging the entire branch down to >>>> trunk. Remaining issues can be dealt with once the branch has been >>>> merged. >>>> >>>> Minor stuff: >>>> >>>> (1) I also would like to propose a few minor changes / renames. Ideally, >>>> I would like the 'steam' package to be fully usable out of the box. So, >>>> it would be good if DefaultBodyDescriptor was moved to 'steam' and >>>> renamed to BasicBodyDescriptor for consistency. I also think >>>> FullBodyDescriptor is a better name for MaximalBodyDescriptor >>> >>> I moved the DefaultBodyDescriptor, and also some method from >>> MimeTokenStream to BasicTokenStream. I'd like to leave the Maximal to >>> Full change for a later step (after merge), but I agree that "Maximal" >>> is not a good name. >>> >>>> (2) I have a number of test cases failing on me when run on Windows. I >>>> think mismatch in line delimiters is the cause. I would be great to have >>>> this fixed before the merge. All test cases used to work on Windows. >>> >>> I double checked this with a new checkout (windows and freebsd) and it >>> worked. I guess this is because you have old resources already checked >>> out and they differs from real resources only for newlines so svn is >>> not correclty updating them. >>> Can you check this on a clean checkout? Can you tell me a specific >>> test that doesn't work (and maybe send me a zip with the original and >>> expected test files so I can bit-compare them with mine?) ? >>> >>>> (3) Tons of javadocs need to be reviewed / updated. I am willing to >>>> help. >>> >>> Maybe we can fix them once we agree that the branch is to be merged. >>> We had no comments from Markus and last comment from Robert was "I >>> will veto any merge attempt".. so I'd like to wait some day to see if >>> they will take into consideration reviewing the code. >> >> Hi Stefano, >> >> Mime4j is not very much on top of my personal priorities right now >> (sorry) but I will try to look into your proposed code changes in the >> next couple of days. >> >> Without having looked into the code I would tend to trust you and Oleg >> to come up with a good solution and a better Mime4j than what we have >> now. >> >> By the way, I think there were no commits to trunk after you started >> your branch. So once consensus is reached it would be possible to "svn >> rm trunk" and "svn mv cycleclean trunk". >> >> The result would be the same as if all development happened in trunk >> so I think in this case there is no reason to veto a merge only >> because it's a merge. >> >> Cheers, >> Markus >> >
