<div dir="ltr"><div><div><div><div><div><div><div>We're undertaking local feature development for ArchivesSpace (ranging from EAD/MARC export tweaking to database migrations and corresponding UI updates); as such, we're setting up code repositories for our local codebase.  Given that the ASpace application doesn't map cleanly to the source repo, it's not immediately clear what the best setup for a code repository will be.<br><br></div>How has the list set up their local code repositories?  Right now, there seem to be a few options for us:<br><br></div>- fork the main ASpace repository, work there, and deploy a full copy of the repo into /plugins/local/ (losing migration/config source control)<br></div>- set up a repo that contains the ASpace application, work in plugins/ (and migrations/ and config/ when needed), and deploy the entire application at once<br></div>- set up a repo of just /plugins/, work there, and deploy that (losing config/migration source control)<br><br></div>We're leaning towards the second option (if only to keep configs/migrations under source control), but none of these implementations feels satisfactory.  Are there other methods of maintaining source control for ArchivesSpace code/config that the list is using?<br><br></div>Thanks,<br></div>--Alex<br clear="all"><div><div><div><div><div><div><div><div><div><div><div><div><div><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Alexander Duryee<div>Metadata Archivist</div><div>New York Public Library</div><div>(917)-229-9590</div><div><a href="mailto:alexanderduryee@nypl.org" target="_blank">alexanderduryee@nypl.org</a></div></div></div></div></div>
</div></div></div></div></div></div></div></div></div></div></div></div></div></div>