You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2015/03/09 17:24:43 UTC
handling old Subversion contents after migrations to Git
Hi all,
As you probably know, we migrated the Proton and new JMS client code
to Git repositories last year. As part of the process the old
locations within the Subversion repo were frozen read-only and left in
place.
Some folks have been caught out by using the old stale locations, as
although we have updated our website with the new locations (and all
the commits@ traffic mentions the new locations) it isnt particularly
clear from the old contents themselves that they are no longer in use
(other than by realising the last commits were a while ago).
I noticed some documentation which indicated as Chair I should be able
to modify the access rights to the old locations, allowing us to edit
them and make things clearer. I checked with infra and that is indeed
the case, although they are also happy to do it for us depending on
the change (e.g move contents to an attic dir, add pointer file).
I wonder what people think we should do:
1. Add pointer files indicating the contents are no longer used and
directing to the Git repos.
2. Delete the trunk dirs, add pointer files to the Git repos.
3. Move the contents to an attic area, add pointer files to the Git
repos in old locations.
4. Delete the contents entirely, dont add pointers.
(The 'deleted' files will obviously remain in Subversion history)
Thoughts?
Thanks,
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: handling old Subversion contents after migrations to Git
Posted by Oleksandr Rudyy <or...@gmail.com>.
+1 for option 3
On 9 March 2015 at 16:24, Robbie Gemmell <ro...@gmail.com> wrote:
> Hi all,
>
> As you probably know, we migrated the Proton and new JMS client code
> to Git repositories last year. As part of the process the old
> locations within the Subversion repo were frozen read-only and left in
> place.
>
> Some folks have been caught out by using the old stale locations, as
> although we have updated our website with the new locations (and all
> the commits@ traffic mentions the new locations) it isnt particularly
> clear from the old contents themselves that they are no longer in use
> (other than by realising the last commits were a while ago).
>
> I noticed some documentation which indicated as Chair I should be able
> to modify the access rights to the old locations, allowing us to edit
> them and make things clearer. I checked with infra and that is indeed
> the case, although they are also happy to do it for us depending on
> the change (e.g move contents to an attic dir, add pointer file).
>
> I wonder what people think we should do:
> 1. Add pointer files indicating the contents are no longer used and
> directing to the Git repos.
> 2. Delete the trunk dirs, add pointer files to the Git repos.
> 3. Move the contents to an attic area, add pointer files to the Git
> repos in old locations.
> 4. Delete the contents entirely, dont add pointers.
>
> (The 'deleted' files will obviously remain in Subversion history)
>
> Thoughts?
>
> Thanks,
> Robbie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
AW: handling old Subversion contents after migrations to Git
Posted by "Aschenbrenner, Erik" <ea...@icubic.de>.
+1 for option 1
-----Ursprüngliche Nachricht-----
Von: Robbie Gemmell [mailto:robbie.gemmell@gmail.com]
Gesendet: Montag, 9. März 2015 17:25
An: users@qpid.apache.org
Betreff: handling old Subversion contents after migrations to Git
Hi all,
As you probably know, we migrated the Proton and new JMS client code to Git repositories last year. As part of the process the old locations within the Subversion repo were frozen read-only and left in place.
Some folks have been caught out by using the old stale locations, as although we have updated our website with the new locations (and all the commits@ traffic mentions the new locations) it isnt particularly clear from the old contents themselves that they are no longer in use (other than by realising the last commits were a while ago).
I noticed some documentation which indicated as Chair I should be able to modify the access rights to the old locations, allowing us to edit them and make things clearer. I checked with infra and that is indeed the case, although they are also happy to do it for us depending on the change (e.g move contents to an attic dir, add pointer file).
I wonder what people think we should do:
1. Add pointer files indicating the contents are no longer used and directing to the Git repos.
2. Delete the trunk dirs, add pointer files to the Git repos.
3. Move the contents to an attic area, add pointer files to the Git repos in old locations.
4. Delete the contents entirely, dont add pointers.
(The 'deleted' files will obviously remain in Subversion history)
Thoughts?
Thanks,
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org
Re: handling old Subversion contents after migrations to Git
Posted by Robbie Gemmell <ro...@gmail.com>.
Pointer files added via http://svn.apache.org/r1675435
On 18 April 2015 at 12:57, Robbie Gemmell <ro...@gmail.com> wrote:
> Thanks for the reminder Chuck. I had meant to get to this when I was
> on vacation last month, but some things happened and I forgot all
> about it.
>
> I raised https://issues.apache.org/jira/browse/INFRA-9471 to request
> they add pointer files, and attached some patches they can use to do
> so.
>
> Robbie
>
> On 17 April 2015 at 22:50, Chuck Rolke <cr...@redhat.com> wrote:
>> Here's the score:
>>
>> Option 1 2 3 4
>> -- -- -- --
>> SH 0 0 1 -1
>> CR 1 0 0 -1
>> EA 1 0 0 0
>> RG 1 0 0 0
>> OR 0 0 1 0
>> TR 0 1 0 0
>> AC 0 1 0 0
>> == == == ==
>> Total 3 2 2 -2
>>
>> It looks like only option 4 is off the table. In the meantime we've done nothing and I've had a remote colleague fall into the stale-proton-svn trap.
>>
>> To be honest any of options 1-3 are fine with me. Robbie, just pick the easiest to execute and go for it!
>>
>> -Chuck
>>
>>
>>
>> ----- Original Message -----
>>> From: "Robbie Gemmell" <ro...@gmail.com>
>>> To: users@qpid.apache.org
>>> Sent: Monday, March 9, 2015 12:24:43 PM
>>> Subject: handling old Subversion contents after migrations to Git
>>>
>>> Hi all,
>>>
>>> As you probably know, we migrated the Proton and new JMS client code
>>> to Git repositories last year. As part of the process the old
>>> locations within the Subversion repo were frozen read-only and left in
>>> place.
>>>
>>> Some folks have been caught out by using the old stale locations, as
>>> although we have updated our website with the new locations (and all
>>> the commits@ traffic mentions the new locations) it isnt particularly
>>> clear from the old contents themselves that they are no longer in use
>>> (other than by realising the last commits were a while ago).
>>>
>>> I noticed some documentation which indicated as Chair I should be able
>>> to modify the access rights to the old locations, allowing us to edit
>>> them and make things clearer. I checked with infra and that is indeed
>>> the case, although they are also happy to do it for us depending on
>>> the change (e.g move contents to an attic dir, add pointer file).
>>>
>>> I wonder what people think we should do:
>>> 1. Add pointer files indicating the contents are no longer used and
>>> directing to the Git repos.
>>> 2. Delete the trunk dirs, add pointer files to the Git repos.
>>> 3. Move the contents to an attic area, add pointer files to the Git
>>> repos in old locations.
>>> 4. Delete the contents entirely, dont add pointers.
>>>
>>> (The 'deleted' files will obviously remain in Subversion history)
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Robbie
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: handling old Subversion contents after migrations to Git
Posted by Robbie Gemmell <ro...@gmail.com>.
Thanks for the reminder Chuck. I had meant to get to this when I was
on vacation last month, but some things happened and I forgot all
about it.
I raised https://issues.apache.org/jira/browse/INFRA-9471 to request
they add pointer files, and attached some patches they can use to do
so.
Robbie
On 17 April 2015 at 22:50, Chuck Rolke <cr...@redhat.com> wrote:
> Here's the score:
>
> Option 1 2 3 4
> -- -- -- --
> SH 0 0 1 -1
> CR 1 0 0 -1
> EA 1 0 0 0
> RG 1 0 0 0
> OR 0 0 1 0
> TR 0 1 0 0
> AC 0 1 0 0
> == == == ==
> Total 3 2 2 -2
>
> It looks like only option 4 is off the table. In the meantime we've done nothing and I've had a remote colleague fall into the stale-proton-svn trap.
>
> To be honest any of options 1-3 are fine with me. Robbie, just pick the easiest to execute and go for it!
>
> -Chuck
>
>
>
> ----- Original Message -----
>> From: "Robbie Gemmell" <ro...@gmail.com>
>> To: users@qpid.apache.org
>> Sent: Monday, March 9, 2015 12:24:43 PM
>> Subject: handling old Subversion contents after migrations to Git
>>
>> Hi all,
>>
>> As you probably know, we migrated the Proton and new JMS client code
>> to Git repositories last year. As part of the process the old
>> locations within the Subversion repo were frozen read-only and left in
>> place.
>>
>> Some folks have been caught out by using the old stale locations, as
>> although we have updated our website with the new locations (and all
>> the commits@ traffic mentions the new locations) it isnt particularly
>> clear from the old contents themselves that they are no longer in use
>> (other than by realising the last commits were a while ago).
>>
>> I noticed some documentation which indicated as Chair I should be able
>> to modify the access rights to the old locations, allowing us to edit
>> them and make things clearer. I checked with infra and that is indeed
>> the case, although they are also happy to do it for us depending on
>> the change (e.g move contents to an attic dir, add pointer file).
>>
>> I wonder what people think we should do:
>> 1. Add pointer files indicating the contents are no longer used and
>> directing to the Git repos.
>> 2. Delete the trunk dirs, add pointer files to the Git repos.
>> 3. Move the contents to an attic area, add pointer files to the Git
>> repos in old locations.
>> 4. Delete the contents entirely, dont add pointers.
>>
>> (The 'deleted' files will obviously remain in Subversion history)
>>
>> Thoughts?
>>
>> Thanks,
>> Robbie
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: handling old Subversion contents after migrations to Git
Posted by Chuck Rolke <cr...@redhat.com>.
Here's the score:
Option 1 2 3 4
-- -- -- --
SH 0 0 1 -1
CR 1 0 0 -1
EA 1 0 0 0
RG 1 0 0 0
OR 0 0 1 0
TR 0 1 0 0
AC 0 1 0 0
== == == ==
Total 3 2 2 -2
It looks like only option 4 is off the table. In the meantime we've done nothing and I've had a remote colleague fall into the stale-proton-svn trap.
To be honest any of options 1-3 are fine with me. Robbie, just pick the easiest to execute and go for it!
-Chuck
----- Original Message -----
> From: "Robbie Gemmell" <ro...@gmail.com>
> To: users@qpid.apache.org
> Sent: Monday, March 9, 2015 12:24:43 PM
> Subject: handling old Subversion contents after migrations to Git
>
> Hi all,
>
> As you probably know, we migrated the Proton and new JMS client code
> to Git repositories last year. As part of the process the old
> locations within the Subversion repo were frozen read-only and left in
> place.
>
> Some folks have been caught out by using the old stale locations, as
> although we have updated our website with the new locations (and all
> the commits@ traffic mentions the new locations) it isnt particularly
> clear from the old contents themselves that they are no longer in use
> (other than by realising the last commits were a while ago).
>
> I noticed some documentation which indicated as Chair I should be able
> to modify the access rights to the old locations, allowing us to edit
> them and make things clearer. I checked with infra and that is indeed
> the case, although they are also happy to do it for us depending on
> the change (e.g move contents to an attic dir, add pointer file).
>
> I wonder what people think we should do:
> 1. Add pointer files indicating the contents are no longer used and
> directing to the Git repos.
> 2. Delete the trunk dirs, add pointer files to the Git repos.
> 3. Move the contents to an attic area, add pointer files to the Git
> repos in old locations.
> 4. Delete the contents entirely, dont add pointers.
>
> (The 'deleted' files will obviously remain in Subversion history)
>
> Thoughts?
>
> Thanks,
> Robbie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: handling old Subversion contents after migrations to Git
Posted by Chuck Rolke <cr...@redhat.com>.
+1 for Option 1
+0 for Option 3
-1 for Option 2
-2 for Option 4
-2 for No Change
Thanks for addressing this issue.
----- Original Message -----
> From: "Robbie Gemmell" <ro...@gmail.com>
> To: users@qpid.apache.org
> Sent: Monday, March 9, 2015 12:24:43 PM
> Subject: handling old Subversion contents after migrations to Git
>
> Hi all,
>
> As you probably know, we migrated the Proton and new JMS client code
> to Git repositories last year. As part of the process the old
> locations within the Subversion repo were frozen read-only and left in
> place.
>
> Some folks have been caught out by using the old stale locations, as
> although we have updated our website with the new locations (and all
> the commits@ traffic mentions the new locations) it isnt particularly
> clear from the old contents themselves that they are no longer in use
> (other than by realising the last commits were a while ago).
>
> I noticed some documentation which indicated as Chair I should be able
> to modify the access rights to the old locations, allowing us to edit
> them and make things clearer. I checked with infra and that is indeed
> the case, although they are also happy to do it for us depending on
> the change (e.g move contents to an attic dir, add pointer file).
>
> I wonder what people think we should do:
> 1. Add pointer files indicating the contents are no longer used and
> directing to the Git repos.
> 2. Delete the trunk dirs, add pointer files to the Git repos.
> 3. Move the contents to an attic area, add pointer files to the Git
> repos in old locations.
> 4. Delete the contents entirely, dont add pointers.
>
> (The 'deleted' files will obviously remain in Subversion history)
>
> Thoughts?
>
> Thanks,
> Robbie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: handling old Subversion contents after migrations to Git
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2015-03-17 at 14:10 -0400, Ted Ross wrote:
> I like #2 (delete the trunk dirs and leave a README with pointers to the
> git repos).
>
+1
> This will eliminate the possibility that someone will use old code or
> think that the project has been abandoned.
>
> -Ted
>
> On 03/17/2015 01:58 PM, Robbie Gemmell wrote:
> > Any other thoughts out there? We seem to have a mix of responses so
> > far, but mostly lots of silence ;)
> >
> > Robbie
> >
> > On 10 March 2015 at 10:05, Robbie Gemmell <ro...@gmail.com> wrote:
> >> On 9 March 2015 at 16:24, Robbie Gemmell <ro...@gmail.com> wrote:
> >>> Hi all,
> >>>
> >>> As you probably know, we migrated the Proton and new JMS client code
> >>> to Git repositories last year. As part of the process the old
> >>> locations within the Subversion repo were frozen read-only and left in
> >>> place.
> >>>
> >>> Some folks have been caught out by using the old stale locations, as
> >>> although we have updated our website with the new locations (and all
> >>> the commits@ traffic mentions the new locations) it isnt particularly
> >>> clear from the old contents themselves that they are no longer in use
> >>> (other than by realising the last commits were a while ago).
> >>>
> >>> I noticed some documentation which indicated as Chair I should be able
> >>> to modify the access rights to the old locations, allowing us to edit
> >>> them and make things clearer. I checked with infra and that is indeed
> >>> the case, although they are also happy to do it for us depending on
> >>> the change (e.g move contents to an attic dir, add pointer file).
> >>>
> >>> I wonder what people think we should do:
> >>> 1. Add pointer files indicating the contents are no longer used and
> >>> directing to the Git repos.
> >>> 2. Delete the trunk dirs, add pointer files to the Git repos.
> >>> 3. Move the contents to an attic area, add pointer files to the Git
> >>> repos in old locations.
> >>> 4. Delete the contents entirely, dont add pointers.
> >>>
> >>> (The 'deleted' files will obviously remain in Subversion history)
> >>>
> >>> Thoughts?
> >>>
> >>> Thanks,
> >>> Robbie
> >>
> >> I should have really added that we dont necessarily have to do the
> >> same thing for both areas of code, i.e the new JMS client and Proton.
> >> The former had the distinction of having no branches or tags, never
> >> having been released, not being particularly usable in the form it was
> >> in at the time, and being quite different from what is there these
> >> days. For me, Option 3 or 4 make most sense for that old code, I dont
> >> expect anyone is looking in there except people randomly broswing the
> >> whole Qpid repo. For the Proton code, I'd probably go for options
> >> 1,3,2,4 in that order.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: handling old Subversion contents after migrations to Git
Posted by Ted Ross <tr...@redhat.com>.
I like #2 (delete the trunk dirs and leave a README with pointers to the
git repos).
This will eliminate the possibility that someone will use old code or
think that the project has been abandoned.
-Ted
On 03/17/2015 01:58 PM, Robbie Gemmell wrote:
> Any other thoughts out there? We seem to have a mix of responses so
> far, but mostly lots of silence ;)
>
> Robbie
>
> On 10 March 2015 at 10:05, Robbie Gemmell <ro...@gmail.com> wrote:
>> On 9 March 2015 at 16:24, Robbie Gemmell <ro...@gmail.com> wrote:
>>> Hi all,
>>>
>>> As you probably know, we migrated the Proton and new JMS client code
>>> to Git repositories last year. As part of the process the old
>>> locations within the Subversion repo were frozen read-only and left in
>>> place.
>>>
>>> Some folks have been caught out by using the old stale locations, as
>>> although we have updated our website with the new locations (and all
>>> the commits@ traffic mentions the new locations) it isnt particularly
>>> clear from the old contents themselves that they are no longer in use
>>> (other than by realising the last commits were a while ago).
>>>
>>> I noticed some documentation which indicated as Chair I should be able
>>> to modify the access rights to the old locations, allowing us to edit
>>> them and make things clearer. I checked with infra and that is indeed
>>> the case, although they are also happy to do it for us depending on
>>> the change (e.g move contents to an attic dir, add pointer file).
>>>
>>> I wonder what people think we should do:
>>> 1. Add pointer files indicating the contents are no longer used and
>>> directing to the Git repos.
>>> 2. Delete the trunk dirs, add pointer files to the Git repos.
>>> 3. Move the contents to an attic area, add pointer files to the Git
>>> repos in old locations.
>>> 4. Delete the contents entirely, dont add pointers.
>>>
>>> (The 'deleted' files will obviously remain in Subversion history)
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Robbie
>>
>> I should have really added that we dont necessarily have to do the
>> same thing for both areas of code, i.e the new JMS client and Proton.
>> The former had the distinction of having no branches or tags, never
>> having been released, not being particularly usable in the form it was
>> in at the time, and being quite different from what is there these
>> days. For me, Option 3 or 4 make most sense for that old code, I dont
>> expect anyone is looking in there except people randomly broswing the
>> whole Qpid repo. For the Proton code, I'd probably go for options
>> 1,3,2,4 in that order.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: handling old Subversion contents after migrations to Git
Posted by Robbie Gemmell <ro...@gmail.com>.
Any other thoughts out there? We seem to have a mix of responses so
far, but mostly lots of silence ;)
Robbie
On 10 March 2015 at 10:05, Robbie Gemmell <ro...@gmail.com> wrote:
> On 9 March 2015 at 16:24, Robbie Gemmell <ro...@gmail.com> wrote:
>> Hi all,
>>
>> As you probably know, we migrated the Proton and new JMS client code
>> to Git repositories last year. As part of the process the old
>> locations within the Subversion repo were frozen read-only and left in
>> place.
>>
>> Some folks have been caught out by using the old stale locations, as
>> although we have updated our website with the new locations (and all
>> the commits@ traffic mentions the new locations) it isnt particularly
>> clear from the old contents themselves that they are no longer in use
>> (other than by realising the last commits were a while ago).
>>
>> I noticed some documentation which indicated as Chair I should be able
>> to modify the access rights to the old locations, allowing us to edit
>> them and make things clearer. I checked with infra and that is indeed
>> the case, although they are also happy to do it for us depending on
>> the change (e.g move contents to an attic dir, add pointer file).
>>
>> I wonder what people think we should do:
>> 1. Add pointer files indicating the contents are no longer used and
>> directing to the Git repos.
>> 2. Delete the trunk dirs, add pointer files to the Git repos.
>> 3. Move the contents to an attic area, add pointer files to the Git
>> repos in old locations.
>> 4. Delete the contents entirely, dont add pointers.
>>
>> (The 'deleted' files will obviously remain in Subversion history)
>>
>> Thoughts?
>>
>> Thanks,
>> Robbie
>
> I should have really added that we dont necessarily have to do the
> same thing for both areas of code, i.e the new JMS client and Proton.
> The former had the distinction of having no branches or tags, never
> having been released, not being particularly usable in the form it was
> in at the time, and being quite different from what is there these
> days. For me, Option 3 or 4 make most sense for that old code, I dont
> expect anyone is looking in there except people randomly broswing the
> whole Qpid repo. For the Proton code, I'd probably go for options
> 1,3,2,4 in that order.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: handling old Subversion contents after migrations to Git
Posted by Robbie Gemmell <ro...@gmail.com>.
On 9 March 2015 at 16:24, Robbie Gemmell <ro...@gmail.com> wrote:
> Hi all,
>
> As you probably know, we migrated the Proton and new JMS client code
> to Git repositories last year. As part of the process the old
> locations within the Subversion repo were frozen read-only and left in
> place.
>
> Some folks have been caught out by using the old stale locations, as
> although we have updated our website with the new locations (and all
> the commits@ traffic mentions the new locations) it isnt particularly
> clear from the old contents themselves that they are no longer in use
> (other than by realising the last commits were a while ago).
>
> I noticed some documentation which indicated as Chair I should be able
> to modify the access rights to the old locations, allowing us to edit
> them and make things clearer. I checked with infra and that is indeed
> the case, although they are also happy to do it for us depending on
> the change (e.g move contents to an attic dir, add pointer file).
>
> I wonder what people think we should do:
> 1. Add pointer files indicating the contents are no longer used and
> directing to the Git repos.
> 2. Delete the trunk dirs, add pointer files to the Git repos.
> 3. Move the contents to an attic area, add pointer files to the Git
> repos in old locations.
> 4. Delete the contents entirely, dont add pointers.
>
> (The 'deleted' files will obviously remain in Subversion history)
>
> Thoughts?
>
> Thanks,
> Robbie
I should have really added that we dont necessarily have to do the
same thing for both areas of code, i.e the new JMS client and Proton.
The former had the distinction of having no branches or tags, never
having been released, not being particularly usable in the form it was
in at the time, and being quite different from what is there these
days. For me, Option 3 or 4 make most sense for that old code, I dont
expect anyone is looking in there except people randomly broswing the
whole Qpid repo. For the Proton code, I'd probably go for options
1,3,2,4 in that order.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: handling old Subversion contents after migrations to Git
Posted by Steve Huston <sh...@riverace.com>.
The only one I'm strongly opposed to is #4.
I slightly prefer #3 of the remaining options. It gets the old content out of the way without deleting it.
> -----Original Message-----
> From: Robbie Gemmell [mailto:robbie.gemmell@gmail.com]
> Sent: Monday, March 09, 2015 12:25 PM
> To: users@qpid.apache.org
> Subject: handling old Subversion contents after migrations to Git
>
> Hi all,
>
> As you probably know, we migrated the Proton and new JMS client code to
> Git repositories last year. As part of the process the old locations within the
> Subversion repo were frozen read-only and left in place.
>
> Some folks have been caught out by using the old stale locations, as although
> we have updated our website with the new locations (and all the commits@
> traffic mentions the new locations) it isnt particularly clear from the old
> contents themselves that they are no longer in use (other than by realising
> the last commits were a while ago).
>
> I noticed some documentation which indicated as Chair I should be able to
> modify the access rights to the old locations, allowing us to edit them and
> make things clearer. I checked with infra and that is indeed the case,
> although they are also happy to do it for us depending on the change (e.g
> move contents to an attic dir, add pointer file).
>
> I wonder what people think we should do:
> 1. Add pointer files indicating the contents are no longer used and directing
> to the Git repos.
> 2. Delete the trunk dirs, add pointer files to the Git repos.
> 3. Move the contents to an attic area, add pointer files to the Git repos in old
> locations.
> 4. Delete the contents entirely, dont add pointers.
>
> (The 'deleted' files will obviously remain in Subversion history)
>
> Thoughts?
>
> Thanks,
> Robbie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional
> commands, e-mail: users-help@qpid.apache.org