On 2011-08-13, Roy Chastain wrote: >>> Who are those people? Maybe they should comment on this?
> I am one of those people. At this point I have minimal (if any) > understanding of the actual patch insertion process, but given I don't > have write privileges that is okay. I also have minimal/no > understanding of how to apply patches that are not "committed" to > something I am building. (I know I need to read the manual.) I have > no allegiance to SVN other than I know I will face it again in the > future. I'll leave the distributed VCS part to Dominik as I think he's more experienced in that area than myself (I'm a long time darcs user with some git sprinkled in but have never used hg or Bitbucket myself). Let me try to address the current process. My I assume you are familiar with TFS? svn is pretty similar to TFS with the major exception being that by default the svn server doesn't track who has checked out what - all your checkouts are local only. This also means "shared checkout" is the default, it is possible to lock files but this is frowned upon. In the eleven+ years I've been working on ASF code bases I've had less than 20 merge conflicts that I needed to resolve - in reality it is very rare that two developers touch the same code at the same time. Commit early and commit often. I am a command line guy so I apply a patch by using the GNU patch command from my Cygwin installation. Unfortunately I'm not familiar with any alternatives to that. The process is "download the patch from JIRA", "apply it to your working copy", "build and test" and finally "commit". > I thought it was a duplication of effort, but Stefan seems to think it > may have merit, so what is the merit? [once I was ready I realized I did talk about the DVCS part as well, sorry. Dominik, please point out where I'm wrong or fill in what I've forgotten to say.] Basically using a site like Bitbucket allows others to have a public workspace they have write access to. This gives those others the advantage of revision control while they develop a feature/fix and gives log4net devs the ability to say "no, don't do it that way, take a different route" and play back and forth until all sides are satisfied. Basing such a workspace on a read-only clone of the "master" svn tree means that this public workspace can be kept in sync with log4net's current code. The distributes VCSes are all pretty good at merging and tracking what they have already merged. Bitbucket, github, launchpad and similar sites make it easy to ship patches from one workspace to another if they are related. Say Dominik had prepared some code change in a workspace and he's ready then he can ask the maintainer of a Bitbucket copy of log4net's svn tree to pull in a certain set of changes - and the infrstructure will perform all necessary merge steps if the request is accepted. A bridge from hg to svn exists that would make it easy to then send the same changes to the svn tree. So what Dominik suggests is to enable a different workflow that is proven and works well for people who are used to these tools. This alternative is more agile and more interactive - several people could be working together on a changeset that is going fix a given bug or implement a given feature - than the "central source tree", "patches in issue tracker", "committer as gateway" process we usually employ. Stefan
