Re: [Jamwiki-devel] git migration

[Peter P. <pit...@us...>]

Hi Thomas,

Am 20.03.2013 um 19:10 schrieb Thomas Koch <th...@ko...>:

> I ran an svn-git conversion yesterday and need your feedback for two 
> decisions. [...]
> 
> The .jar files alone make up more than 40MB. I propose to remove all .jar 
> files from the history.


*hmmm* Is the SVN repository kept available online at SourceForge after migration has been finished?
If yes, I wouldn't really mind, as history is kept intact.

> I don't think that anybody plans to build the versions 
> from the pre-maven era. It's nice and important to have the history of the 
> java files from this time, but it's a burden to carry old .jar cruft around.

True, but in the end a SCM is supposed to enable revision safe state tracking. We should, somehow, provide the full and uncut history; No matter if someone right now want's to use it for production relevant things ... But that's just my 2 cents ...

> Additionally I found more files that I propose to delete. They might not even 
> be in the trunk branch:

Maybe I'm pedantic, but I wouldn't do, without compensation.
If we decide to "make a cut" and keep revisions "up to xxx" available for separate download, or checkout from still available SVN, I'm fine with this.
But if you want to do a search "where does XYZ come from" you need a complete data basis. 

Unless I'm the only one, having this wish. In this case I'd not fight any deletion decision.

> I've pushed a git clone with those files removed to:
> https://github.com/thkoch2001/jamwiki-wiki-conversion-wip

Thanks.

> I've lost the branches during the conversion. But I could do the conversion 
> again with the branches, if you want.

I'd prefer so, unless ... I know, I repeat myself ... we keep a separate history available (and therefore officially "(somehow) start from scratch").

There's http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git

It additionally describes how to keep tags ... Which, IMHO, are even more important than branches (especially if they don't even differ significantly - in sense of unmerged code - from trunk).

If development roadmap is "Next release will be 2.x" and "We make a kind of 'restart' including SCM house keeping", "For historical data see [SVN dump as compressed archive in SF files section or still read-only accessible SVN]" ... As from my perspective: let's go ahead!
-- 
Best regards,

Peter

PS: Never mind the last commit to branch "pitpalme", if the decision is to cut history. I'll easily be able to re-apply it to a new repository!