[Archivesspace_Users_Group] ArchivesSpace codebase repository setup

[Alexander Duryee]

Chris,

Thanks!  We'll definitely try that out to keep our code up-to-date.

What we aren't clear on is the best method of turning our fork of
https://github.com/archivesspace/archivesspace into something deployable.
Should we fork the repository, commit to the fork, run the build system,
and deploy the build?  Or would it be wiser to fork the repository, commit
to the fork, then copy any new code to a plugins repository (which then
gets deployed)?

Regarding plugins - is there any real limitation as to how far plugins can
go before we would need to start rolling our own builds?

Thanks,
--Alex

On Fri, Mar 11, 2016 at 3:29 PM, Chris Fitzpatrick <
Chris.Fitzpatrick at lyrasis.org> wrote:

>
> Hi,
>
>
> One thing you can do is to just set and upstream repo in git. I.e. :
>
>
> 0 ) Fork the main archivesspace/archivesspace repo and clone it
>
> 1 ) Add an upstream remote to your clone (  git remote add upstream
> https://github.com/archivesspace/archivesspace.git )
>
> 2 ) now you can pull down any upstream changes ( git pull upstream master,
> or make a branch first, pull the upstream into that branch, then merge the
> brance into your master )
>
>
> Does that make sense?
>
> b,chris.
>
>
>
> Chris Fitzpatrick | Developer, ArchivesSpace
> Skype: chrisfitzpat  | Phone: 918.236.6048
> http://archivesspace.org/
>
>
> ------------------------------
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
> Alexander Duryee <alexanderduryee at nypl.org>
> *Sent:* Friday, March 11, 2016 8:08 PM
> *To:* Archivesspace Users Group
> *Subject:* [Archivesspace_Users_Group] ArchivesSpace codebase repository
> setup
>
> 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.
>
> How has the list set up their local code repositories?  Right now, there
> seem to be a few options for us:
>
> - fork the main ASpace repository, work there, and deploy a full copy of
> the repo into /plugins/local/ (losing migration/config source control)
> - 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
> - set up a repo of just /plugins/, work there, and deploy that (losing
> config/migration source control)
>
> 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?
>
> Thanks,
> --Alex
>
> --
> Alexander Duryee
> Metadata Archivist
> New York Public Library
> (917)-229-9590
> alexanderduryee at nypl.org
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Alexander Duryee
Metadata Archivist
New York Public Library
(917)-229-9590
alexanderduryee at nypl.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160311/c879210c/attachment.html>