Hi Thomas, hi Ryan,
Am 22.03.2013 um 06:52 schrieb Ryan Holliday <ryan.holliday@...>:
> Hi Thomas,
>> Keeping the .jar files in the history would blow up the repository for
>> everybody for the rest of the life of the jamwiki project without any benefit.
>> Working with the repository only becomes slower.
> Losing the JAR files wouldn't be a huge problem, given the trade-off of
> repository size. Old JAMWiki WAR files are available for download, SVN
> will probably still be available, so losing JARs from old source code
> history seems like an acceptable trade-off.
I agree. If SVN is continued to be available there's no gain in transferring superfluous JAR files (that should never have made it to the SOURCE code management!) to git and only blow up it's size.
I was only concerned about them getting lost completely and therefore establishing a situation that would make it impossible to re-build and older revision.
That trade off is OK to me, as it's not the job of a new SCM to enable the most easiest way to re-build a historic version.
>> I propose to review which branches we want to keep and to put the rest in some
>> dark hidden corner of the internet.
> With regards to branches, as long as the release branches are kept
> (branches/0.9.x, etc) and the release tags can be maintained then I
> don't think anything else is needed. Peter - if you feel differently
> please say so.
I don't. SVN doesn't do branch tracking as Git, so there's no gain.
All merges belong solely to destination trunk, so the commit log information where it originates from provides all information; Any further technical tracking of the original source is "manual work" anyway, so it can be done in SVN as well.
I even don't mind about "my" personal branch; There's no problem in recreating it.
All I see as "necessary" is - beneath "trunk" (or "master") - the release branches and tags.
Everything else is an add-on :-)
> Thanks for your work on this.
Let me step into this chorus! Thanks for doing the job, I wouldn't have been able these days, due to workload.
A little coding "by the way": yes; The focus requiring and time consuming SCM migration: sadly not right now :-)