+1 on github<br><br>On Tuesday, March 27, 2012, thomas bonfort <<a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a>> wrote:<br>> I'm currently importing the trac tickets into github. We should be<br>
> able to keep ticket numbers intact (could be used to write rewrite<br>> rules for trac tickets). The references to the commits (r1234<br>> notation) in summaries and comments are converted to git sha1s with<br>
> links to the actual commit.<br>><br>> The ticket assignee isn't correct but will be (I'm not activating this<br>> yet to avoid email notifications). All the tickets and comments will<br>> be marked as if they were added by me, however the userid of the<br>
> original poster is added to the body of each of these elements.<br>><br>> the link to the full project is <a href="https://github.com/tbonfort/mstmp">https://github.com/tbonfort/mstmp</a><br>><br>> the branches aren't yet pushed there but that would be the case later on.<br>
><br>> Given that Daniel's reticences towards history are resolved by this<br>> outcome, I would like to get this moving again with new comments, or<br>> start voting asap (I have spent alot of effort on this already, and<br>
> don't have much free time left to do the actual transition)<br>><br>> regards,<br>> thomas<br>><br>> On Fri, Mar 23, 2012 at 17:48, thomas bonfort <<a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a>> wrote:<br>
>> On Fri, Mar 23, 2012 at 17:04, Daniel Morissette<br>>> <<a href="mailto:dmorissette@mapgears.com">dmorissette@mapgears.com</a>> wrote:<br>>>> On 12-03-23 7:37 AM, thomas bonfort wrote:<br>>>>><br>
>>>> I've written RFC84:<br>>>>><br>>>>> <a href="http://mapserver.org/development/rfc/ms-rfc-84.html">http://mapserver.org/development/rfc/ms-rfc-84.html</a><br>>>>><br>
>>>> (not published yet, should appear soon, for now:<br>>>>><br>>>>> <a href="http://trac.osgeo.org/mapserver/browser/trunk/docs/en/development/rfc/ms-rfc-84.txt">http://trac.osgeo.org/mapserver/browser/trunk/docs/en/development/rfc/ms-rfc-84.txt</a>)<br>
>>>><br>>>>> /me ducks<br>>>>><br>>>><br>>>> Hi Thomas,<br>>><br>>> Hi Daniel,<br>>> thanks for your answer<br>>><br>>>><br>>>> Thank you for putting this together and for your efforts trying to make old<br>
>>> timers (such as me) see the light. My silence of the last few days was<br>>>> because I was swamped with other stuff, and not due to a lack of interest.<br>>>><br>>>> First of all, as I already said in Seattle, I am a happy Trac/SVN camper and<br>
>>> don't see a need to move, but OTOH I am always open to being shown better<br>>>> ways to do things, that's why I like to have guys like you Howard and Alan<br>>>> around and poking me, so I will not get in your way as long as my primary<br>
>>> concerns below can be addressed... I'll even work with you to find<br>>>> solutions. :-)<br>>>><br>>>> (And yes I still miss Bugzilla as was pointed out on IRC recently... I<br>
>>> always will until a better tool shows up ;-) , and even if I am used to Trac<br>>>> today and prefer it for some aspects, it's seriously lacking on some stuff<br>>>> that Bugzilla provided several years ago such as powerful search features<br>
>>> and ticket dependencies.)<br>>>><br>>>> Ok, so back to the git topic. My primary concerns are:<br>>>><br>>>> P1 - Maintain complete history of commits and tickets<br>>>> P1 - Ability to migrate in a few years<br>
>>><br>>>> And<br>>>><br>>>> P2 - Offsite backups/mirrors<br>>>> P2 - Reliability of the service<br>>>> P3 - Maintain commits vs tickets references in the tools we use<br>
>>><br>>>> The availability of new features or the ease of use of the new workflow<br>>>> don't worry me too much. I trust that you would not be spending all that<br>>>> energy if the proposed approach was not better in general.<br>
>>><br>>>><br>>>> Please let me elaborate on each concern:<br>>>><br>>>> * P1 - Maintain complete history of commits and tickets<br>>>><br>>>> I do care a lot about maintaining the history of the project for a<br>
>>> combination of reasons:<br>>>><br>>>> - Practical reasons: I go back in ticket and commit history very often when<br>>>> I'm troubleshooting problems, to understand why/when something was changed<br>
>>> or why it was implemented in a given way. History is also useful to identify<br>>>> whether a given feature was available or broken in e.g. version 4.10 or only<br>>>> in 5.2. Losing this is not an option for me.<br>
>>><br>>>> - Legal reasons: The complete history of commits and tickets can sometimes<br>>>> be used to track down the provenance of a given block of code and confirm<br>>>> our rights to use it. And the other way around, the history could even be a<br>
>>> way to demonstrate that MapServer had feature or algorithm x or y<br>>>> implemented before someone else filed a patent on that feature for instance.<br>>>><br>>>> - Coolness factor: It's just cool to be able to replay 12 years of commit<br>
>>> history. ;-)<br>>><br>>> History of the code: everyone will have it in their checkout, offline,<br>>> so you'll have the coolness factor of replaying your twelve year<br>>> history on a plane. As such everybody also has a backup of the whole<br>
>> history, which does not preclude maintaining a more official backuping<br>>> system elsewhere.<br>>><br>>> History of the tickets: is keeping the trac instance online a viable<br>>> option for the ticket history? Basically put, if you need the full<br>
>> ticket history synchronized with the git code and new tickets, this<br>>> precludes us from using github.<br>>> For me, the ticket history is