Re: selfupdate-git

Hi Dustin, all,


thanks for your email!

On 01.08.2012, at 18:43, Dustin Cartwright wrote:

> On Wed, Aug 1, 2012 at 8:34 AM, Max Horn <[email protected]> wrote:
> 
>> On 31.07.2012, at 15:58, D H wrote:
>> > For me git is the better choice, especially since we are a distributed
>> > open source project
>> 
>> .... I mean unlike this "argument by analogy", which is not an actual argument. Hey, I like git more than SVN, too, but I don't think git is the perfect answer to everything. And in this case, so far I saw more convincing arguments pro-SVN than pro-git. Of course, perhaps we can use *BOTH*, as I already stated in my prior email, that would then neatly solve the problem. But this should first be carefully tested and evaluated.
> 
> I'll make the case that if there's ever a project that could benefit from distributed source control, it's the fink dists repository. Lots of open source projects have many developers spread over the world, but dists repository is an one extreme case in that it has hundreds of maintainers, each of which are "core" for their packages. Most of these don't have write access to the dists repository and so are basically doing version control by hand. 
> 
> Specifically, as someone without commit rights, if I want to update a package, what I do is copy the info and maybe patch file to my local tree, make my modifications, and submit it on the SF tracker. Then some core member comes along, downloads the files to their local tree, maybe does a diff against the old package, tries to build it, and if it works copies it to the stable tree and commits the changes. 
[...]
> With git and github, modifying someone else's package and submitting a pull request to them is as easy as submitting a pull request to the main repository.
> 
> The point in both scenarios is that git makes it easy to make changes without sending them immediately to the master repository. They can be filtered through the package maintainer or a core developer, and at each stage everyone's benefiting from having a version control system, not just the final commit to master.

Thanks, that is an excellent point. Yes, that could potentially make lifes a lot easier for both maintainers who want to submit new or updated packages, as well as core staff who needs to review and merge (or reject) updates. 

Fully agreed. I still think, however, that not all maintainers will be able or willing to reap in these benefits by first learning to use git and github.

Hence, I still favor the dual-pronged approach of offering both git and svn access: For those who want minimal learning effort and minimal changes, we'll recommend SVN; for those who know git or are willing to learn it, we recommend that. And of course people can at any time switch from one to the other!


> 
> Finally, I also suggest that maybe the dists repository could be organized with the different OS versions (10.4 and 10.7) as branches rather than subdirectories.

We discussed this in the past, too.

> This would make it easier to make changes on 10.4 and then sync them over to 10.7 or vice versa. In fact, it would be nice to have a different branch for each version (10.5, 10.6, 10.7, and 10.8) if there was someone to keep 10.5 "tied" with 10.6 and 10.7 "tied" with 10.8. This makes EOL'ing an OS version straightforward: just stop automatically synching it.

How would that work, from a technical point of view? Keep in mind that it should be as automated as possible, else it won't happen (we are already lacking manpower). Do you mean this: In the conversion, we would have a 10.7 and a 10.8 branch. However, these branches would refer to the same commit. Whenever something is committed to the 10.7 branch, the 10.8 branch is automatically increment to still point to the same branch as 10.7. That is, until the day were we decide that the two branches need to diverge (e.g., because 10.7 support ends, or for any other good reason). After that, the separate syncing would stop. However, if some individuals still want to maintain the EOLed 10.7 tree, they could be granted permission to do so (just as is happening with the "10.4-EOL tree right now, only 
 much more elegantly).

The crucial part here seems to me the question on how to keep the two branches in sync... Perhaps a special hook script in the repos could take care of that.

A simpler (in terms of technical requirements) solution would be to do this: We start out with just two branches, 10.4 and 10.7. Then, we somehow provide a map which maps Distribution values to branch names (this map could be part of the dists repository, so that it gets updated along with the packages when doing a selfupdate). E.g. it could initially contain this:
 10.4 => 10.4
 10.5 => 10.4
 10.6 => 10.4
 10.7 => 10.7
 10.8 => 10.7

 When we EOL 10.4 support (well, we already did, of course), then what we do is this: We create a new 10.5 branch, based on 10.4. And update the map to look like this:
 10.4 => 10.4
 10.5 => 10.5
 10.6 => 10.5
 10.7 => 10.7
 10.8 => 10.7

And so on. Advantage: No hooks or technical tricks required. 


> One big downside is that changing the repository structure probably means that the CVS history can't be copied into the git repository.

I think that's not a serious problem. Indeed, I think we could arrange things so that the 10.4-EOL stuff would become the 10.4 branch, while the regular parts of 10.4/ would become the 10.5 branch. Indeed, I think with some effort and good user of git filter-branch, this is no problem at all :).


> 
> That's my case for git, but I agree that it is harder to use than svn. Part of the reason is that git supports many different workflows. One way to make this easier is to have wrappers which handle implement whatever the policy will be for submitting packages, which is the most common task that most developers will need.

As I said, I love git myself... I am just reluctant to force all maintainers to use it, because whhile I appreciate the many advantages it brings, I have too often experienced the pains it can also bring to the "not yet enlightened". ;).

Hence, I really, *really* hope we can get the dual git + svn approach to work well...



Cheers,
Max
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
fink-core mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core