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" <robbie.gemm...@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-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
