Anyone object to me moving MoreLINQ to Mercurial?

[Jon Skeet]

Hey folks,

We've had a request to accept some more code, which sounds great to me - but I'd rather do it via Mercurial than Subversion.

Does anyone object to me converting our Subversion repository to Mercurial? I can't remember how easy it is to do that any keep the commit history, but I'll do my best. Any thoughts?

Jon

[Johannes Rudolph]

I'd say go for it. I have had a good time with the hg convert extension. I think google code does also have some tips/recommendations (and maybe automated tooling too) around this. 

Johannes

--
You received this message because you are subscribed to the Google Groups "MoreLINQ Developers" group.
To post to this group, send email to moreli...@googlegroups.com.
To unsubscribe from this group, send email to morelinq-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/morelinq-dev?hl=en.

[Atif Aziz]

Hi Jon,

I'd support the move from Subversion to Mercurial and I've done that with nearly all my projects hosted here on GC. However, the history migration is not very straightforward and we have one branch pending merge. I wouldn't blindly convert now. If we can make the merge while in Subversion and then move to Mercurial then it would also enable us to take a number of simpler options with the history, like just taking over the trunk.

- Atif

Jon

[Jon Skeet]

Right, let's try to merge (or abandon the other branch). I seem to remember that when I looked at the branch it had various things I was really dubious about, but I'll try to take another look this week. We should definitely just take trunk after resolving this.

Jon

[Atif Aziz]

Jon, I wouldn't consider the branch dubious at all. It has very valuable contributions, perhaps the most significant to date. If I didn't find some of them already done in F#, I would have been more aggressive about getting them into the MoreLINQ trunk. :) I had started the reviewing and merging on one of my boxes but never got round to completely finishing and committing. I remember I was close so I can go ahead and do that some time this week unless you see a showstopper. Mind you, we can always continue to tweak those operators after the move to Hg, even outright delete them if they end up causing trouble.

- Atif

[Jon Skeet]

I think we may be talking about different branches, or perhaps different aspects of different branches. There are currently four different branches in svn, plus trunk:

• EvenMoreLinq
• linqish-to-datatable
• split
• reorg

The EvenMoreLinq contains various "new" bits, including the ModelShredder part (which feels like a "bigger" extension than I'm really comfortable with in MoreLINQ).

I don't think we should take the whole branch completely - I'd like to visit each extra operator separately, I think. This feels like it's potentially going to be a longer review process. I'm sure there's a lot of good stuff in there, but keeping consistency and a reasonably high utility bar (rather than this becoming a completely kitchen-sink project) is important IMO.

(Let's tidy up to 4 spaces instead of tabs, and always use braces while we're at it, btw. The current code looks horrible in Google code, in places.)

Jon

[Atif Aziz]

The EvenMoreLinq contains various "new" bits, including the ModelShredder part (which feels like a "bigger" extension than I'm really comfortable with in MoreLINQ).

ModelShredder is gone. It was reviewed and re-factored into something more LINQ-ish (see discussion) in the linqish-to-datatable branch and then finally merged into the trunk as the single extension method ToDataTable. I think EvenMoreLinq branched out before that so still contains ModelShredder and company and that will automagically disappear when EvenMoreLinq branch is merged too.

I also merged the reorg branch into trunk back in r82 and which is reviewed as issue #23.

linqish-to-datatable and reorg are really historical branches and could be “closed”, so to speak, by simply deleting them. It would certainly reduce clutter and confusion in case we need to pick this up again 3 years from now. ;) The split branch, on the other hand, is still pending your review. :)

As for EvenMoreLinq…

I don't think we should take the whole branch completely - I'd like to visit each extra operator separately, I think. This feels like it's potentially going to be a longer review process. I'm sure there's a lot of good stuff in there, but keeping consistency and a reasonably high utility bar (rather than this becoming a completely kitchen-sink project) is important IMO.

If the review process risks getting long then it could stall the move to Hg, current potential momentum from awaiting contributors and eventually the whole project. MoreLINQ hasn't had any serious activity in 2 years and some of those reviews have been open for as long. I have reviewed EvenMoreLinq and am content with the submission and its quality (inclusion of unit tests, documentation and examples). Most of the proposed operators are not surprising and borrow from sequence operations available in many other libraries and run-times (including F#). If you'd still like to take the time to review in details then I can understand and support the decision but then we shouldn't let the current choice version control system bother us. If you have requests to accept code then I think that can still be done using the classic approach of submitting patches.

- Atif

I don't think we should take the whole branch completely - I'd like to visit each extra operator separately, I think. This feels like it's potentially going to be a longer review process. I'm sure there's a lot of good stuff in there, but keeping consistency and a reasonably high utility bar (rather than this becoming a completely kitchen-sink project) is important IMO.

- Atif

[Jon Skeet]

Alternatively, we could just go ahead with the merge and conversion, and I can always delete or change things afterwards in Mercurial :)

It sounds like you're in the best situation to do the merging, if you're happy to do so. If you're able to tidy up the spaces/tabs and bracing at the same time, that'd be great - but don't worry too much.

Now I've got a bit more experience with Sandcastle (via Noda Time) I'll set up a project so we can have API docs on Google Code.

Jon

[Atif Aziz]

Good call on the alternative & yes there'll be room to party on the code later. ;) I'll take care of the merging & conversion (long weekend with potential rain on the horizon so who knows it might be sooner than later :)) & it'd be great if you can take the lead on Sandcastle.

- Atif

[Atif Aziz]

OK, the Subversion to Mercurial is done with full history of the project! I have surgically removed the EvenMoreLINQ branch and will be adding it back as a clone. I've already done this with Split already and opened a new review request that points to the clone and merged the old issue into it. The benefit is that we can continue the review and merge when done so we're in the same state as before.

- Atif

[Atif Aziz]

Wiki pages (well, just two for now) have also now been restored with full history.

- Atif