Re: Subversion 1.1-286-trunk-merge branch to SVN trunk move plan

[Ate Douma <at...@douma.nu>]

CDoremus@hannaford.com wrote:
> Hi all,
>  
> It seems that everyone is OK with moving the Subversion 
> 1.1-286-trunk-merge branch to the SVN trunk. I intend on doing that on 
> Monday night (East Coast USA time), so please voice your comments and 
> concerns by that time.
>  
> Here's my basic plan. Since I am not an Subversion guru, please comment 
> or correct me if I am wrong.
> 1. SVN tag the current trunk. I'm not sure how to name this tag so it is 
> not confused with other tags in Subversion that are official releases. 
> Suggested names are appreciated.
> 2. SVN delete the trunk.
> 3. Immediately svn copy the 1.1-286-trunk-merge-branch to the trunk. I 
> am aware that there is a 'SVN move' option, but I want to make sure that 
> things go OK, so I'd rather copy and diff the copy with the old branch 
> as a double check.
Well, you can do that, but I think by copying we might lose the history recorded against the branch which I definitely think is a bad idea.
If you move it, all its history is moved along.
In my experience, moving is painless and harmless with svn as long as you do it directly on the server, *don't* try to do it locally and commit that.

>  
> Here are a couple of other things to do with our SVN repository later:
> 1. Delete the 1.1-286-trunk-merge branch (after it has been copied to 
> the trunk and checked).
> 2. Delete the 1.1-286-COMPATBILITY branch. I'd like Torsten and the Univ 
> of Jena group to give the OK before this is done.
I advise against doing that. That branch also contains quite a lot of commit history with many related JIRA issues.
After the 2.0 release, I might be ok to drop it, but not now.

> 3. Create a tag when Pluto is submitted with the JSR-286 specification 
> as the JSR-286 Reference Implementation to the Java Community Process 
> for approval. Ate has suggested that we do this. We could call this tag 
> JSR286-RI (other suggested names are welcome). I'm not sure of the 
> timing of this (please comment Stefan)?
PJSR286-RI sounds fine, +1

>  
> BTW, I also created a 2.0.0 version in Jira and moved all 
> 1.1-286-trunk-merge issues into it.
See also my comment above: the 1.1.-286-COMPATABILITY branch related JIRA issues too might be viewed as "2.0.0" related, even if their svn commit info is tied 
to that branch.

>  
> Thanks to all of you for your hard work on Pluto to make this move 
> possible, especially Torsten and the Univ of Jena group.
> /Craig
+1, and a lot of thanks to you too Craig as you also worked very hard to make this happen!

Regards,

Ate

Re: Subversion 1.1-286-trunk-merge branch to SVN trunk move plan

[Eric Dalquist <er...@doit.wisc.edu>]

 From a Pluto integrators point of view this sounds like a great plan 
and will definitely help clear up what is available, actively maintained 
and where Pluto is going.

-Eric

Ate Douma wrote:
> Elliot Metsger wrote:
>>
>>
>> Ate Douma wrote:
>>> CDoremus@hannaford.com wrote:
>>>> Hi all,
>>>>  
>>>> It seems that everyone is OK with moving the Subversion 
>>>> 1.1-286-trunk-merge branch to the SVN trunk. I intend on doing that 
>>>> on Monday night (East Coast USA time), so please voice your 
>>>> comments and concerns by that time.
>>>>  
>>>> Here's my basic plan. Since I am not an Subversion guru, please 
>>>> comment or correct me if I am wrong.
>>>> 1. SVN tag the current trunk. I'm not sure how to name this tag so 
>>>> it is not confused with other tags in Subversion that are official 
>>>> releases. Suggested names are appreciated.
>>>> 2. SVN delete the trunk.
>>>> 3. Immediately svn copy the 1.1-286-trunk-merge-branch to the 
>>>> trunk. I am aware that there is a 'SVN move' option, but I want to 
>>>> make sure that things go OK, so I'd rather copy and diff the copy 
>>>> with the old branch as a double check.
>>> Well, you can do that, but I think by copying we might lose the 
>>> history recorded against the branch which I definitely think is a 
>>> bad idea.
>>> If you move it, all its history is moved along.
>>> In my experience, moving is painless and harmless with svn as long 
>>> as you do it directly on the server, *don't* try to do it locally 
>>> and commit that.
>>
>> I agree, it should be a server-side operation.  SVN history should be 
>> preserved no matter if it is a copy or a move.  A move is just an 
>> 'Add' followed by a 'Delete' where a copy is just an 'Add'.
> True, I just tested it out and for the SVN history it really doesn't 
> matter.
> I brought this up though because I thought a client tool like the 
> Eclipse Subversive plugin would be better capable of "tracking" the 
> history with a move, but it turns out that doesn't matter either: it 
> isn't capable of comparing two revisions if both are no longer in the 
> same path :(
>
>> Still, performing a move versus a copy is cleaner.
> I agree.
>
>>
>>>> 3. Create a tag when Pluto is submitted with the JSR-286 
>>>> specification as the JSR-286 Reference Implementation to the Java 
>>>> Community Process for approval. Ate has suggested that we do this. 
>>>> We could call this tag JSR286-RI (other suggested names are 
>>>> welcome). I'm not sure of the timing of this (please comment Stefan)?
>>> PJSR286-RI sounds fine, +1
> Looking at the current used tag names, pluto-x.x.x, maybe 
> pluto-JSR-286-RI might be more in line and descriptive, especially if 
> people do check the tag out using its default folder name.
> But JSR286-RI also is still fine by me too.
>
>>
>> sounds good to me too.
>>
>> In general I'm concerned about the history issues (I'm more concerned 
>> that all these branches sprouted up to begin with).  The good news is 
>> that when those branches are removed, they aren't truly gone.  They 
>> are still available in previous revisions of the repository, even if 
>> the branch is gone in current and future revisions of the repository.
> Yes, and if the need would arise we can always recreate such a branch 
> from its last revision.
>
> Regards,
>
> Ate
>

Re: Subversion 1.1-286-trunk-merge branch to SVN trunk move plan

[Ate Douma <at...@douma.nu>]

Elliot Metsger wrote:
> 
> 
> Ate Douma wrote:
>> CDoremus@hannaford.com wrote:
>>> Hi all,
>>>  
>>> It seems that everyone is OK with moving the Subversion 
>>> 1.1-286-trunk-merge branch to the SVN trunk. I intend on doing that 
>>> on Monday night (East Coast USA time), so please voice your comments 
>>> and concerns by that time.
>>>  
>>> Here's my basic plan. Since I am not an Subversion guru, please 
>>> comment or correct me if I am wrong.
>>> 1. SVN tag the current trunk. I'm not sure how to name this tag so it 
>>> is not confused with other tags in Subversion that are official 
>>> releases. Suggested names are appreciated.
>>> 2. SVN delete the trunk.
>>> 3. Immediately svn copy the 1.1-286-trunk-merge-branch to the trunk. 
>>> I am aware that there is a 'SVN move' option, but I want to make sure 
>>> that things go OK, so I'd rather copy and diff the copy with the old 
>>> branch as a double check.
>> Well, you can do that, but I think by copying we might lose the 
>> history recorded against the branch which I definitely think is a bad 
>> idea.
>> If you move it, all its history is moved along.
>> In my experience, moving is painless and harmless with svn as long as 
>> you do it directly on the server, *don't* try to do it locally and 
>> commit that.
> 
> I agree, it should be a server-side operation.  SVN history should be 
> preserved no matter if it is a copy or a move.  A move is just an 'Add' 
> followed by a 'Delete' where a copy is just an 'Add'.
True, I just tested it out and for the SVN history it really doesn't matter.
I brought this up though because I thought a client tool like the Eclipse Subversive plugin would be better capable of "tracking" the history with a move, but 
it turns out that doesn't matter either: it isn't capable of comparing two revisions if both are no longer in the same path :(

> Still, performing a move versus a copy is cleaner.
I agree.

> 
>>> 3. Create a tag when Pluto is submitted with the JSR-286 
>>> specification as the JSR-286 Reference Implementation to the Java 
>>> Community Process for approval. Ate has suggested that we do this. We 
>>> could call this tag JSR286-RI (other suggested names are welcome). 
>>> I'm not sure of the timing of this (please comment Stefan)?
>> PJSR286-RI sounds fine, +1
Looking at the current used tag names, pluto-x.x.x, maybe pluto-JSR-286-RI might be more in line and descriptive, especially if people do check the tag out 
using its default folder name.
But JSR286-RI also is still fine by me too.

> 
> sounds good to me too.
> 
> In general I'm concerned about the history issues (I'm more concerned 
> that all these branches sprouted up to begin with).  The good news is 
> that when those branches are removed, they aren't truly gone.  They are 
> still available in previous revisions of the repository, even if the 
> branch is gone in current and future revisions of the repository.
Yes, and if the need would arise we can always recreate such a branch from its last revision.

Regards,

Ate

Re: Subversion 1.1-286-trunk-merge branch to SVN trunk move plan

[Elliot Metsger <em...@jhu.edu>]

Ate Douma wrote:
> CDoremus@hannaford.com wrote:
>> Hi all,
>>  
>> It seems that everyone is OK with moving the Subversion 
>> 1.1-286-trunk-merge branch to the SVN trunk. I intend on doing that on 
>> Monday night (East Coast USA time), so please voice your comments and 
>> concerns by that time.
>>  
>> Here's my basic plan. Since I am not an Subversion guru, please 
>> comment or correct me if I am wrong.
>> 1. SVN tag the current trunk. I'm not sure how to name this tag so it 
>> is not confused with other tags in Subversion that are official 
>> releases. Suggested names are appreciated.
>> 2. SVN delete the trunk.
>> 3. Immediately svn copy the 1.1-286-trunk-merge-branch to the trunk. I 
>> am aware that there is a 'SVN move' option, but I want to make sure 
>> that things go OK, so I'd rather copy and diff the copy with the old 
>> branch as a double check.
> Well, you can do that, but I think by copying we might lose the history 
> recorded against the branch which I definitely think is a bad idea.
> If you move it, all its history is moved along.
> In my experience, moving is painless and harmless with svn as long as 
> you do it directly on the server, *don't* try to do it locally and 
> commit that.

I agree, it should be a server-side operation.  SVN history should be 
preserved no matter if it is a copy or a move.  A move is just an 'Add' 
followed by a 'Delete' where a copy is just an 'Add'.  Still, performing 
a move versus a copy is cleaner.

>> 3. Create a tag when Pluto is submitted with the JSR-286 specification 
>> as the JSR-286 Reference Implementation to the Java Community Process 
>> for approval. Ate has suggested that we do this. We could call this 
>> tag JSR286-RI (other suggested names are welcome). I'm not sure of the 
>> timing of this (please comment Stefan)?
> PJSR286-RI sounds fine, +1

sounds good to me too.

In general I'm concerned about the history issues (I'm more concerned 
that all these branches sprouted up to begin with).  The good news is 
that when those branches are removed, they aren't truly gone.  They are 
still available in previous revisions of the repository, even if the 
branch is gone in current and future revisions of the repository.

Elliot