All right - I started a PoC by simply making a git svn clone of the AspectJ
maven plugin's trunk (our SVN repo is not structured in a manner which
lends it to simple conversion preserving all tags following a git/svn
cloning).
Although I have not put a lot of hours into validating the consistency of
the git repository, it is certainly enough for starting the much needed
work. My plan is doing the modernization job in Git and push back changes
into SVN at decently regular intervals.
One question which immediately pops up is the licensing WRT the AspectJ
maven plugin.
The LICENSE.txt file is an MIT license, rather than, say, Apache2. What is
our praxis here? Leave the MIT license, or attempt to migrate to another?
2013/6/29 Baptiste MATHUS <bmat...@batmat.net>
>
>
>
> 2013/6/29 Stephen Connolly <stephen.alan.conno...@gmail.com>
>
>>
>>
>> On Saturday, 29 June 2013, Fred Cooke wrote:
>>
>>> You forgot that Maven tooling is in many ways not working correctly for
>>> DVCS users, especially the majority who are using Git.
>>
>>
>> Or is it that the majority of people using git and maven want to use git
>> in a different way from the way that works best with maven?
>>
>> I use maven and git all the time in my day job and personal projects. I
>> have yet to find any issue other than the mutability of git tags... Which
>> is not a major issue for me.
>>
>
> +1. I wanted to comment on that point too and forgot.
> We've been using Git & Maven for 3 years at job, and use the m-release-p
> on many multimodules projects without issue.
> So I don't understand what your general point is about. There sure may be
> some cases where this is complicated, but I don't see us at mojo be
> concerned.
>
>
>
>>
>> Perhaps the issue is actually the git usage pattern of others being
>> poorly aligned with maven.
>>
>> Btw do not confuse debate over the content of release vote emails with
>> potential issues in the release plugin.
>>
>> (Personally I view version numbers as cheap, so I don't respin borked
>> releases with the same version number in day job or personal projects, so
>> that may "streamline" away some potential issues)
>>
>> For this reason if there was any voting going on, which this thread
>>> wasn't about anyway, I'd vote +1 for mirroring experiment and -1 for
>>> ditching SVN all together at this point ("migration"), no matter how much I
>>> hate it.
>>>
>>
> I don't think we actually want SVN to be "ditched" immediately after the
> migration.
> Just set it readonly so that people don't commit there by mistake.
> That's what we did some years ago when switching from svn to many Git
> repos. And those SVN repos are still accessible today on the corp svn
> server, though I don't think many people go there.
>
> Cheers
>
> -- Baptiste
>
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
