RE: the complete "rebuild" of the existing DSpace/DSpace GitHub.
I'm also OK with rebuilding it entirely (and re-mapping all SVN users ->
GitHub Users). However, I agree with Peter Dietz, that we should rename
the existing "DSpace/DSpace" to "DSpace/DSpace-pre-official" (or perhaps
"DSpace-pre-migration" or "DSpace-unmaintained"). We should also post a
warning to all users that they need to switch to 'forking' the new
I've updated our migration docs to detail this:
On 3/16/2012 4:00 PM, Peter Dietz wrote:
> As I thought about this a bit more, I did somewhat have a change of
> heart, and kind of think we ought to "properly" redo it.
> Imagine when DSpace migrates to xyz-version-control in a decade. We'll
> all be emeritus, and wondering where our place in history is. And the
> future people migrating the code will be like, hey, home come there's
> two different mappings for authors.
> Another possible question, is people who have svn commits, but will not
> be creating github accounts, those commits need to be swallowed by a
> user. So either ping everyone else to be like, hey, can you create an
> account, otherwise we dump all their commit attribution onto another
> user. I'm not sure what happens if you have a partial author mapping.
> And to address the, hey, your broke my fork of you. We could leave
> DSpace/DSpace renamed to DSpace/DSpace-pre-official until everyone
> un-forks it, and then we just spend the half-day fixing forks.
> So, consider me talked-in-and-out of shall we.
> Peter Dietz
> On Fri, Mar 16, 2012 at 4:39 PM, Mark Diggory <mdiggory@...
> <mailto:mdiggory@...>> wrote:
> On Wed, Mar 14, 2012 at 11:53 AM, Peter Dietz <pdietz84@...
> <mailto:pdietz84@...>> wrote:
> Hi All,
> Since we're now ready to migrate all of the remainder code to
> GitHub, two questions have popped up.
> 1) Should we stick with the existing Github.com/dspace/dspace
> repository, or should we reimport (a fresh git svn clone) so
> that we can use the author mapping to make old commits point to
> a user's GitHub profile? By pushing that change, it would make
> the current repo incompatible with anyone who has forked it, as
> the reimport would have completely different commitID's.
> I think we should drop the existing repo and reimport with corrected
> authors. Unless there is any possible means to just update the
> existing repo with the authors. Yes this will be a pain for those
> of us who have forked... but were actually the ones capable of
> managing this migration.
> 2) What should we do about languages? We have dspace-xmlui-lang
> <http://scm.dspace.org/svn/repo/modules/dspace-xmlui-lang/trunk/src/main/webapp/i18n/> and
> <http://scm.dspace.org/svn/repo/modules/dspace-api-lang/trunk/src/main/resources/> I
> don't imagine that people like having to manage
> two separate language files. So would we want to consolidate
> that into a single project? If so, anyone up to doing the work
> for that refactoring? Where would messages/language extensions
> for modules fit?
> Each project is "separate" and meant to be updated separately. If
> we want to merge and refocus this so that language updates are part
> of minor releases, I'm ok as it will probably lead to less confusion
> for the community. This means that dspace-api-lang would go under
> dspace-api/src/main/resources and that dspace-xmlui-lang would go
> under dspace-xmlui/src/main/webapp/
> Finally, I want to toss in that my Maven project consolidation
> coding combined with the above will really simplify dspace build...
> @mire Inc.
> *Mark Diggory *(Schedule a Meeting
> /2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/
> /Esperantolaan 4, Heverlee 3001, Belgium/
> http://www.atmire.com <http://www.atmire.com/>