[cle-release-team] Sakai Trunk in Transition

[Matthew Jones]

Yeah, it looks like svndumpfilter has some limitations.

I'm seeing this other program svndumpfilter3 which claims to be better at
figuring out the move and copy operations.
http://furius.ca/pubcode/pub/conf/bin/svndumpfilter3.html

synsync might be able to figure it out too? It looks like the only thing
that might lose is the original author of the commit.

I agree that leaving them with a note is a good idea.  I also don't
consider it a huge deal for these projects. Unfortunately reverse merging a
delete messes up the history a little too. (Did that a few times
accidentally)




On Thu, Feb 13, 2014 at 9:42 AM, Anthony Whyte <arwhyte at umich.edu> wrote:

> I propose that we just copy and commit the hierarchy &
> external-calendaring-service projects directly into core svn. This will not
> retain the svn history, but will avoid the risk of having the load fail and
> 30,000+ "empty revisions" left in the repository *(since svn does not
> apparently clean up nicely after a failed load). I'll be on the 10am calll
> to discuss.
>
>
> +1.  Both modules are small relative to other projects.  However, if you
> are not able to retain history, do not delete the code in contrib as part
> of cleanup.  Add a readme to the old contrib location that notes that the
> modules have been moved to core (without history) and that the contrib repo
> is being retained as an historical archive.
>
> Cheers,
>
> Anth
>
>
> anthony whyte | its and mlibrary | university of michigan |
> arwhyte at umich.edu | 517-980-0228
>
>
> On Feb 13, 2014, at 7:26 AM, Kirschner, Beth wrote:
>
> Thanks Matt! Here's a followup on what's left. I'd like to discuss at the
> 10:00am call.
>
> There are a total of 5 repos to be moved from contrib -> core. Three of
> these (roster2, signup, delegatedaccess) were dumped cleanly without error.
> Greg & I are continuing to load these into core this morning.
>
> The remaining 2 (hierarchy & external-calendaring-service), did not dump
> cleanly, due to having their svn paths changed over time. I've tried two
> different svndumpfilter commands: the one from yesterday, which failed, and
> another today that generated these warnings:
>
> WARNING 0x0000: The range of revisions dumped contained references to copy
> sources outside that range.
> WARNING 0x0001: The range of revisions dumped contained mergeinfo which
> reference revisions outside that range.
>
> I propose that we just copy and commit the hierarchy &
> external-calendaring-service projects directly into core svn. This will not
> retain the svn history, but will avoid the risk of having the load fail and
> 30,000+ "empty revisions" left in the repository *(since svn does not
> apparently clean up nicely after a failed load). I'll be on the 10am calll
> to discuss.
>
> Thoughts?
> - Beth
>
> On Feb 12, 2014, at 5:54 PM, Matthew Jones <matthew at longsight.com> wrote:
>
> Okay, I think I got (a) fixed for svn and contrib. (changed ownership of
> the files that were root in these directories back to apache)
>
>
> Let me know if how it goes with the other parts!
>
>
>
>
>
> On Wed, Feb 12, 2014 at 5:35 PM, Matthew Jones <matthew at longsight.com>
> wrote:
>
> Yeah, bummer,
>
>
> a) This should be resolvable, do you have my Skype? Send me a message and
> let me know what you think should be done as I think I have root here.
>
> b) It sounds like we're stuck with this unless we want to shut down the
> svn repo, dump and try to re-filter that. Since we're going to have to move
> soon anyway, I'd just make note of the first and last revision that this
> happened and we can filter and fix this then?
>
> c) Not sure about this, maybe it will work after (a) is resolved
>
>
>
>
> On Wed, Feb 12, 2014 at 5:21 PM, Kirschner, Beth <bkirschn at umich.edu>
> wrote:
>
> a) Resolve commit problem
>
> b) Remove empty revisions, but this might not be possible. Empty revisions
> were removed during the svndumpfilter process, but apparently added as
> placeholders during the failed load.
>
> c) Find how to load the two repos (external-calendaring-service and
> hierarchy) that were moved while in contrib
>
>
> I guess no good deed goes unpunished. Ideas welcome. I'll continue digging.
>
>
> - Beth
>
>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140213/159ee20d/attachment-0001.html