You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2003/11/15 20:56:49 UTC
[all] Policies concerning migration from sandbox
I think both our latest adventure in the math cvs tree and the existing
discussion about stale sandbox projects warrants some consideration of a
standardized policy for migration out of the sandbox.
I think the current Wiki:
http://nagoya.apache.org/wiki/apachewiki.cgi?MovingFromSandboxToProper
Should be augmented with a process which maintains the cvs tree history
on migration from the sandbox and that this approach should be promoted
over the existing cvs import approach.
This will involve the following steps:
<snip>
3. Actual CVS move for project "foo":
- Log in to your Apache cvs account on cvs.apache.org:
- go to your sandbox project directory
$cd /home/cvs/jakarta-commons-sandbox/foo
- back it up to your local account
$tar -cvf ~/jakarta-commons-sandbox-foo.tar .
- go to the commons and create a new directory for your project
$cd /home/cvs/jakarta-commons
$mkdir foo
$chmod 775 foo
$cd foo
- Expand your backup tarball into this directory
$tar -xvf ~/jakarta-commons-sandbox-foo.tar
- Verify that group permissions are correct across the subdirectories.
$find . -type d -exec chmod 775 {} \;
- Verify that group permissions are correct across the files.
$find . -type f -exec chmod 444 {} \;
- Verify that your project can be cvs checked out and built properly by
yourself and others.
- Verify that you and others can cvs commit properly in new directory.
Finally, remove the old cvs project directory from the sandbox:
$rm -Rf /home/cvs/jakarta-commons-sandbox/foo
Please review this process and provide any comments/thoughts,
Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Policies concerning migration from sandbox
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Bill Barker wrote:
> "Mark R. Diggory" <md...@latte.harvard.edu> wrote in message
>>Finally, remove the old cvs project directory from the sandbox:
>>
>>$rm -Rf /home/cvs/jakarta-commons-sandbox/foo
>>
>>
>>Please review this process and provide any comments/thoughts,
>>Mark
>
>
> I would do a cvs delete for the final step (for recovery only), but
> otherwise, you've got a +1 from the peanut-gallery. It's really annoying
> that the history for commons-daemon stops at the import point, so I can't
> (easily) go back and compare to prior versions when I have a problem with
> it.
The downfall in this is that up to that point we've worked hard to
migrate all the history that was in this original location to the new
location. Doesn't this make saving the original history by cvs deletion
now an unnecessary duplication?
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Policies concerning migration from sandbox
Posted by Bill Barker <wb...@wilshire.com>.
"Mark R. Diggory" <md...@latte.harvard.edu> wrote in message
news:3FB68501.8090106@latte.harvard.edu...
> I think both our latest adventure in the math cvs tree and the existing
> discussion about stale sandbox projects warrants some consideration of a
> standardized policy for migration out of the sandbox.
>
> I think the current Wiki:
> http://nagoya.apache.org/wiki/apachewiki.cgi?MovingFromSandboxToProper
>
> Should be augmented with a process which maintains the cvs tree history
> on migration from the sandbox and that this approach should be promoted
> over the existing cvs import approach.
>
> This will involve the following steps:
>
> <snip>
> 3. Actual CVS move for project "foo":
>
> - Log in to your Apache cvs account on cvs.apache.org:
>
> - go to your sandbox project directory
>
> $cd /home/cvs/jakarta-commons-sandbox/foo
>
> - back it up to your local account
>
> $tar -cvf ~/jakarta-commons-sandbox-foo.tar .
>
> - go to the commons and create a new directory for your project
>
> $cd /home/cvs/jakarta-commons
> $mkdir foo
> $chmod 775 foo
> $cd foo
>
> - Expand your backup tarball into this directory
>
> $tar -xvf ~/jakarta-commons-sandbox-foo.tar
>
> - Verify that group permissions are correct across the subdirectories.
>
> $find . -type d -exec chmod 775 {} \;
>
> - Verify that group permissions are correct across the files.
>
> $find . -type f -exec chmod 444 {} \;
>
> - Verify that your project can be cvs checked out and built properly by
> yourself and others.
>
> - Verify that you and others can cvs commit properly in new directory.
>
> Finally, remove the old cvs project directory from the sandbox:
>
> $rm -Rf /home/cvs/jakarta-commons-sandbox/foo
>
>
> Please review this process and provide any comments/thoughts,
> Mark
I would do a cvs delete for the final step (for recovery only), but
otherwise, you've got a +1 from the peanut-gallery. It's really annoying
that the history for commons-daemon stops at the import point, so I can't
(easily) go back and compare to prior versions when I have a problem with
it.
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org