lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per Steffensen <>
Subject Re: pro coding style
Date Sat, 01 Dec 2012 16:18:58 GMT
Michael Sokolov skrev:
> This kind of information (merge tracking) has been in svn since 1.5 
> (see 
> I believe this perception of SVN dates from its early days, when 
> merging was indeed much more difficult: you had to keep track of all 
> the merges you had done, to avoid doing them again, and it was a huge 
> mess.  That has pretty much been sorted out now.
Ok, so the necessary tracking of data seems to be in both. One might be 
better that the other in some aspects and visa versa. I stand corrected.
> Now it seems to me that the main advantage about git/github is that it 
> doesn't create a strict boundary between committers and 
> non-committers.  As a committer, the two systems are basically the 
> same up to differences in UI, convenience of tools, etc. 
> But for a non-committer, with SVN the situation is irritating if you 
> submit patches that you continue to use, but are not accepted (or not 
> in a timely way) into the main repository.  In such a case, you either 
> have to abandon the use of source control (OUCH!), or you have to fork 
> the entire project and maintain your own repo, with no tools for 
> integrating with the main repo.
> My understanding is that with git, you can maintain your own repo, and 
> you have tools for taking changes from upstream repos, and also that 
> the "pull request" mechanism may be more convenient than submitting 
> patches.  So this sounds, on the whole, much more attractive for 
> outside contributors.  I have to admit I've only fiddled with this a 
> bit, so this is mostly based on what I've read and heard: please "tell 
> me that I am stupid"!
> -Mike

With change/merge-tracking in both system, the important thing must be 
that you do not have to throw the tracked information away before in you 
attempt to get your changes into the main repository. You certainly 
throw this information away when you create a dumb patch-file. Guess 
that we could make it work, if just "outsiders" where allowed to make 
branches in Apaches SVN - we are not :-) So I guess that is the main 
bennefit of git. It allows for forks from the main repository to live 
remote from the main repository - that is, I would be able to make a 
fork from the Apache git-repository (github or not), a fork that "lives" 
entirely on my system of servers. And when I want to forward changes 
into Apache it can go from my forked repository into the main repository 
(through upstreaming) without having to cross a border where the nice 
change/merge-tracking is lost. Still pretty sure that the stuff for this 
is all in git, but depeding on whether or not Apache would need access 
to my local repository (containing my fork) in order for the upstream 
from my repository to the Apache repository to be possible, when the 
actual action of accepting the upstream has to be on the Apache side, I 
dont know. With GitHub my repository would live the same place as 
Apaches and then certainly it would be possible. But why the discussion? 
Why not just GitHub?!

Regards, Per Steffensen

View raw message