[Archivesspace_Users_Group] ArchivesSpace codebase repository setup

[Chris Fitzpatrick]

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<mailto:alexanderduryee at nypl.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160311/0e881b02/attachment.html>