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 <mdigg...@atmire.com> wrote:
>
>
> On Wed, Mar 14, 2012 at 11:53 AM, Peter Dietz <pdiet...@gmail.com> 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
>> dspace-api-lang<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...
> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation
>
> Mark
>
> --
> [image: @mire Inc.]
> *Mark Diggory *(Schedule a
> Meeting<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg>
> )
> *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
> *Esperantolaan 4, Heverlee 3001, Belgium*
> http://www.atmire.com
>
>
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
