Posted by aufumy on September 16, 2008 at 6:53pm
When I gained cvs access, I read the drupal book pages on cvs and also merlinofchaos blog, and polled irc drupal-support.
What I came up with was that there are 2 ways of maintaining releases for contributed modules.
1) Always have the latest code in head, and only release a branch when the new version of drupal comes out. For example when working with module and it is for drupal5 the code is found under HEAD, when the module is upgraded for drupal6, create a branch DRUPAL-5 for the drupal5 module.
2) Don't worry about having HEAD updated, and only work in the branches for the code specific to that drupal version.
I came to prefer option #2. This issue came back to my forefront after talking with mroswell.
Any thoughts, opinions?
Comments
Right, so...
Number 1 is the way recommended by Derek Wright, our CVS maintainer. It's also consistent with the way that core works, and I believe is how CVS is intended to work. In this way, HEAD always becomes "The latest and greatest code that's available."
Number 2 is my personal preference, since it's much easier for me to grok "If you want to update Drupal 6 code, you need to be in -r DRUPAL-6--1. If you want to update Drupal 7 code, you need to be in -r DRUPAL-7--1." I also run my sites off CVS checkouts most of the time, and it's highly annoying to cvs up one day and all of a sudden get Drupal 7 code rather than Drupal 6.
However, I have been corrected by dww and add1sun that that's not the proper way to do things. :P So you should go with #1. :P
Well, I am definitely in the
Well, I am definitely in the #1 camp but I am more and more realizing that people simply get more confused by it. Unless you take the time to understand CVS, #1 is harder to grok. And, let's be honest, how many people really care about understanding it? They just want to use it. For most people it is just a tool they have to use to get on to their main objective. And that is totally cool.
So, anyway, I am inclined to let #2 lie for those that it helps get through the CVS minefield.
Lullabot loves you
Learn Drupal online at Drupalize.me
#2
Count me in the #2 camp. Derek has tried to teach me "the Walk" but it just doesn't work for me (maybe being old AND blonde). I also have trouble getting -dev releases coming out if I don't do the #2 way.
Whether or not it is the CVS-way, it just makes more sense to me to stick with the branches all the way down the line.
Nancy Dru
Nancy Dru
My deduction, which is
My deduction, which is likely to be mostly supposition and hyperbole is this:
Number 1 would work if most contrib module maintainers were cvs ninjas (as add1sun mentioned) and also developer ninjas, and when a new version of drupal was released, such as drupal7, most would soon after upgrade their module to drupal7, and thus creating a drupal6 branch of their module at this time.
Thus, when a drupal site is being deployed, and the latest stable drupal version is used, the core can be checked out as DRUPAL-6 and contrib modules as DRUPAL-6--1 (or DRUPAL-6--2, ...) rather than checking out as DRUPAL-6 and HEAD, and then as webchick mentioned possibly suffer a drupal7 upgrade of that module at the next cvs checkout.
Using number 2 would help reduce the amount of checking required to make sure whether HEAD is still for the version of drupal expected or if there has been a branch created between the last cvs update.
Also it may help with automation, and statistics of modules and their versions, making it clearer from cvs checking out with -r {version} (without having to browse to the webpage for the project of cvs web gui) to determine drupal versions of modules available.
I think the real problem is
I think the real problem is that we let each project maintainer decide. This is one of those places where consistency is best. I wish dww declared a best practice on this topic. I personally would like to see us standardize on #2 but thats less important than consistency.
Go chix!
That's the plan ;-)
Moshe, next on my list for the CVS docs is to do just that: standardize on one way. And that way will be #2. ;-)
I still plan to document #1 but as an "Advanced CVS ninja thingy".
Lullabot loves you
Learn Drupal online at Drupalize.me
Compromise standardization would be ok with me.
A while ago, I documented a 3rd "best practice" for dealing with HEAD here:
http://drupal.org/node/17570#HEAD
Scroll down to the very bottom where there's a heading called "Only sync changes to HEAD when you're going to start a new branch". I'd be willing to see us standardize on that as a compromise from the Ninja style I employ and the crazy people who remove all the files from HEAD and make branches off branches off branches forever. It would be nice to always have branches named with the version they belong to, and HEAD release nodes are definitely the most complicated and support-generating of the bunch.
My minor concern about that
My minor concern about that one is "sometimes you work in a branch, sometimes you work in HEAD." Thats slightly more complex than it needs to be. "Always work in a branch" is simpler, and totally deprecates release nodes for HEAD. I'm not opposed to your proposal, but consider mine.
For contrib maintainers
I have to agree with Moshe. The contrib maintainers need to keep a pseudo-HEAD for each Drupal release and possibly current development. So the contrib could have -dev branches for 5.x, 6.x and 7.x. The way Project is setup there is no method for a contrib to create a 7.x -dev release other than creating a branch so HEAD is out of the picture in this scenario.
promoting the same idea?
Are you sure that your proposal and dww's are all that different? You do believe in making branches off of HEAD, right?
You said "sometimes you work in a branch, sometimes you work in HEAD." but that's not really the advice of that section. You only work in HEAD for 1 revision where you synch back and then you instantly create a new branch and work in the new branch.
I think you are both promoting the same idea.
FWIW, I prefer the so-called "ninja" method but agree that consistency is far more important and I would happily support the "always work in a branch, but synch back to head before making a new branch."
knaddison blog | Morris Animal Foundation
Re: promoting the same idea?
I have a branch for version 1 and one for version 2. They are both actively worked. I want to support both versions for D5, D6 and D7. Which one's changes get synced with HEAD?
crazy talk (but of course possible)
I've never seen anyone do this, but of course it's possible.
Note that in this example "sync with HEAD" is something you do only once right before the release and is not an ongoing process.
knaddison blog | Morris Animal Foundation
Nested branches are ok if there's a limit
a) Yes, this is crazy talk, I doubt many people actually have 6 branches being actively maintained like this.
b) I have no problem with a little branch nesting, so long as there's a limit. Recursion is fine, but you need a base case. ;) Let's say you've got DRUPAL-6--1, DRUPAL-7--1 and DRUPAL-8--1 branches, and you decide you want to add a 2.* series for each one. I have no problem with you making the DRUPAL-6--2 branch off the end of the DRUPAL-6--1 branch, ditto DRUPAL-7--2 off the end of DRUPAL-7--1. Perhaps the documents/proposal should be amended to say:
"... before you start a new branch for a new version of core, always sync back to HEAD and create your new branch from there."
Also, if you're making a new branch for new features for the latest version of core you support, you can/should also sync back to HEAD. (In the above example, DRUPAL-8--2 should ideally be from a re-sync with HEAD). But that's more important for modules like OG that have 7 branches for a given version of core than it is for something like views. This last part is mostly a style question -- if you plan to have more than 2 or 3 nested branches, you should avoid them...
Different schools ...
Different people belong to different schools of thoughts on this one.
I am in the camp where HEAD is always stateless, and not anything to build on from. So count me in the "always work from a branch" gang.
The most recent branch is the one that has all the action. If I need to move from 6.x to 7.x, I sync HEAD from 6.x, branch it to 7.x (DRUPAL-7--1), and then build a -dev tarball from that. When the time comes for 8.x, then the starting point will be the 7.x, copy to HEAD, branch it and the cycle repeats.
The exception of building tarballs from HEAD can be convenient for some, but it is confusing to a large part of our dev base.
I am hesitant to forbid it outright, because there are too many people building tarballs off of HEAD, but at least we can discourage this in the documentation and promote a standard way of doing things that do not have too many exceptions. Make it easier for everyone, and support will go down too. Simplicity is always better. Exception cases are always problematic.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
OK good - we are all on the
OK good - we are all on the same page I think. I misunderstood dww's suggestion to use HEAD only for one revision. That sounds fine. Although, it would be the tiniest bit simpler to create the new branch right from the previous branch. So if I want to start work on D7, I would go to my tip of D6 and do a cvs tag -b DRUPAL-7--1. I never tried that, but it would work, no? Is there some problem with that? Would it confuse people? The advantage is that we can say 'forget about HEAD - it is never used'.
Screws the numbering scheme
It should work, since project integration with CVS only cares about the tag, not how it is created.
But it would screwup the numbering scheme that CVS uses. You know this strange system of number with dots between them for revisions. But that is obscure enough for most people, and only interests dww and hunmonk when we call them in on the scene of a crime for forensics.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
I would go to my tip of D6
It'd work, and that'd be fine...assuming that you don't mind revision numbers like, say, 1.133.2.14.2.10.2.24.2.114:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/ecommerce/c...
(Sorry to pick on you, e-commerce folks)
Personally, I find that somewhat horrifying, and while I think we could get by with massive proliferating revision numbers, I'd rather there be something in place which kept them to a conceptually manageable size. But, that also necessitates route #3 of dww's writeup, which is indeed well-described as the ninja route. So that's a bind.
At first, I thought it might be possible to resolve it by updating the cvs hooks such that whenever a
cvs tag -b DRUPAL-7--1or similar operation is performed, the hook script transparently branches back to HEAD, then back out to the new branch. At that point, though, we're delegating a potentially problematic write operation to a script, which is never a good idea.But another question arises out of this - having not played with cvs hook scripts, how possible would it be to spruce up the error messages that are returned to the client? Putting some instructions in there based on what they're doing that's disallowed could be nifty...
Error messages from CVS
a) There are config settings for all kinds of error messages that our custom validation scripts generate. See contributions/modules/cvslog/xcvs/xcvs-config.php. The copy on d.o is different, but that should at least give you an idea of what's possible.
b) Most GUIs refuse to display the error messages generated at the CVS server, so many people don't see these messages unless they use the CLI. :( Damn CVS GUIs.
I hate to sidetrack this....
In this case, is the patch below useful at all? What would it take to get this implemented?
http://drupal.org/node/267313
I don't think we are looking
I don't think we are looking to forbid anything. The main issue is that there are multiple ways documented so many people get confused very quickly. I am planning to simply make "#2" the standard way that is consistently documented, especially for anyone just hitting this for the first time. I don't see any problem with people following #1 if they know what they are doing. I would like to document it as well, just wall it off in an "advanced" place for those that want to.
Lullabot loves you
Learn Drupal online at Drupalize.me
#3 is what I'm aiming for
I definitely agree with "#3", i.e. resyncing HEAD. I actually interpret #2 as that. I really, really don't like clearing HEAD and branching from branches. My idea with #2 is exactly what you have proposed. I forgot that some people, like really, forget HEAD and never go back to it.
Lullabot loves you
Learn Drupal online at Drupalize.me
Clarification of the options
Argh, much confusion still reigns in here. I'm going to restate each option, the pros/cons, and then provide pseudo code for the instructions for making a new branch to try to clarify what we're actually talking about here. For all the examples, let's say the current situation is that there's a 6.x-1.* release series and someone wants to start working on new features for 6.x-2.*.
Option #1 is what's been called the "ninja" approach. It can be summarized as "Always do your latest development in HEAD and have your release nodes explain what version that is." Probably the most "ninja" part of this is what happens when you want to start using HEAD for something else, make a branch, move the branch on your HEAD release node to point to another branch, and then create a new HEAD release node with the new version number. That's complicated, and I'm not surprised people are confused or get it wrong.
Making a new branch for 6.x-2.x-dev with #1:
- decide the branch name that your current HEAD belongs in for posterity, in this case "DRUPAL-6--1"
-
% cvs update -A# update workspace to latest HEAD-
% cvs tag -b DRUPAL-6--1# save the current 6.x-1.* from HEAD into a new branch- edit the current 6.x-1.x-dev release node and change it from HEAD to point to DRUPAL-6--1
- create a new release node pointing at HEAD and correctly call it 6.x-2.x-dev
Option #2 is the "never use HEAD for anything -- always make branches off branches". This has the pro of always having a self-documenting branch. It has the con of making the CVS revision numbers for your files insane (as per the ecommerce example above), which makes CVS archeology more difficult, makes the $Id$ tags at the tops of files get crazier and crazier, and generally can cause trouble for tools designed to work with CVS. @add1sun: please do NOT document this as the one recommended best practice, or I'll be very sad.
Making a new branch for 6.x-2.x-dev with #2:
-
% cvs update -r DRUPAL-6--1# update workspace to latest DRUPAL-6--1-
% cvs tag -b DRUPAL-6--2# make a new branch from the end of DRUPAL-6--1 for 6.x-2.*- create a new release node pointing at DRUPAL-6--2 which will automatically be called 6.x-2.x-dev.
Option #3 is the compromise I documented and linked to above. It can be summarized as "Always work in a self-documenting branch, but always sync to HEAD for 1 revision before you make new branches going forward". I don't think that's all that complicated, and certainly not really "ninja" material as sdboyer suggests. If we just clearly document that with example commands to run and explain why it's worth syncing to HEAD for each new branch, I bet developers will be willing/able to do it. There's nothing that conceptually hard about this, and people never have to mess with HEAD release nodes.
Making a new branch for 6.x-2.x-dev with #3:
-
% cvs export -d 6.x-1 -r DRUPAL-6--1 contributions/modules/foo# Get a "6.x-1" directory tree with no CVS dirs-
% cvs co -d head contributions/modules/foo# Get a clean HEAD workspace in a dir called "head"-
% cp -r 6.x-1/* head# clobber all the files from HEAD with the latest copies from DRUPAL-6--1-
% cd head-
% cvs diff -up# always run this before committing. ;)-
% cvs commit -m "Syncing HEAD with the latest code from DRUPAL-6--1"-
% cvs tag -b DRUPAL-6--2# make a new branch from the end of HEAD for 6.x-2.*- create a new release node pointing at DRUPAL-6--2 which will automatically be called 6.x-2.x-dev.
I'll grant that #3 is definitely more complicated than #2, but probably less complicated than #1 overall. And, while there's no way we could have the contrib repo do this for you, I'd be more than happy to make and/or review a little script that automated as much of #3 as possible. Also, there's a ninja approach for #3 involving cvs update -j and using release tags to remember where you merged from, but I'm not going to document (or try to automate) that. ;)
I'm definitely opposed to actually preventing option #1. Keep in mind, #1 is how core is handled. If there's ever a catch-all best practice for contrib, the mantra has always been: "Do what core does"...
I'm definitely opposed to
The only significant difference here is that core has very very little back porting of features from one branch to another.
It's that very scenario that makes managing multiple branches very confusing for many.
Thank you all for the
Thank you all for the clarifications. Now that I understand the disadvantages of #2, I am fully in support of #3 and will be using that procedure from now on. It is a little bit more learning, but not that much more.
#3 and CVS merge commands
I was under the impression that the best way to do the CVS merging was to actually merge over the branch using the
-jflag forcvs update, not copy the contents from one branch to another. Cederqvist recommends something like this:$ cvs checkout -d head contributions/modules/foo # Fresh checkout of head$ cd head
$ cvs update -j DRUPAL-6--1 # Merge branch over head
$ cvs diff -up
$ cvs commit -m "Merged dev branch back into HEAD" # Check the merged branch back in.
$ cvs tag -b DRUPAL-6--2
(For the example upon which this is based, see http://ximbiot.com/cvs/manual/cvs-1.11.23/cvs_5.html#SEC60)
This has the advantage of allowing CVS to manage all of the additions and deletions of files. As I understand it, your method above would require new files to be manually added, and deleted files to be manually deleted. Is there still a reason to favor that method over the Cederqvist-recommended one?
Blog: http://technosophos.com
QueryPath: http://querypath.org
What do you do with the
What do you do with the changes in HEAD you don't want in DRUPAL-6--2? A merge combines the code, it doesn't replace it.
I am convinced that for contributed modules the HEAD version should remain empty, the drupal branch tags be created from HEAD and the module branch/release tags be created from those drupal branch tags. You might want to support multiple versions of your module on multiple versions of Drupal and it becomes a nightmare trying to use HEAD for the control point of branch/release tags.
Joining the Conversation
As a CVS learner still, I'll admit to not being as savvy as most in this post, but I'd like to point out a little logic that's been creeping my way as I understand CVS more. And that is simply this:
As a maintainer of a couple of modules that depend solely on other modules (as opposed to core) I have absolutely no use for HEAD whatsoever. HEAD in this case is just an obtuse construct of confusion... I depend solely on webform being up to date for Drupal 7... and with so many changes coming down the pipe for cck and fields (I know this is completely irrelevant I'm just making a point) I have to wait until that's been settled on and webform figures out which way it's going to go before I can even start upgrading my module to match and continue working. As I said the details are irrelevant, but something similar to this will be true from one version of core to the next and so on... I'll almost certainly NEVER work in HEAD as the modules I depend on probably won't start their own upgrades until core is either frozen, or out for general consumption, at such time I'll endeavor to upgrade them. For someone in my situation (dependent upon other devs, which many... maybe "most" modules are) HEAD makes absolutely no sense.
From a cvs ninja point of view, I can understand how HEAD might be useful, but that's not your average dev, and as I said, I think it's more a construct of confusion, so if we can eliminate that confusion, then ++ from me.
With that said my final point (and dww, I don't pretend to understand the details of CVS, but I'd like to have this one concern addressed).
From one version to another of a given module apis and file structures change. Informing CVS of these changes is... not easy. So in theory, it's nice to say "resync" to head any time you're creating a new branch... but in practice this could be an amazing chore if someone has learned better practices, understand drupal better, or simply wants to be better organized. (which we hope ALL our devs fall into all these categories) This will require that people eventually learn most of the ins and outs of really making CVS work properly (which I'm not saying is a bad thing)... but as compared to option #2... which is essentially a "life hack" it's certainly not as easy... and if we're going to go that far, it might be better to simply make people learn option #1.
Again as I said, I don't actually pretend to be informed on this, but it's my "not-completely-educated" opinion of the situation, and I thought I'd toss it out there for contemplation.
Eclipse
HEAD
I think you are probably confused about what HEAD is. Basically, HEAD is like a somewhat special branch. Each module in the repository has its own HEAD, and the HEAD of your module doesn't have to have any connection to Drupal core HEAD or the HEAD of any other module. I think the basic idea of Derek's proposal to change the best practice is that HEAD is not very descriptive. If I check out the HEAD of a module, how do I know what version of Drupal this is for? I don't, unless I look through the .info file, or read the code, or see if that module has a dev snapshot release that points to HEAD, in which case I can see what version it's for by looking at the release node.
If, instead of using HEAD for active development, we suggest that people always do active development in a real branch, that real branch will make it obvious what version of core the module is following. For example, with a branch named DRUPAL-6--1, you know that the code in that branch of the module will be (or at least should be) compatible with Drupal 6. There's nothing technically wrong about developing code for Drupal 6 in HEAD of your module instead of the DRUPAL-6--1 branch, but it's just more obvious if you develop in a true and explicitly named branch instead of HEAD.
You may be right that HEAD is "an obtuse construct of confusion" (that really should be the motto for CVS, IMO), but you could use HEAD for development if you wanted to.
As for your question to dww, I don't follow what you're asking. When you say "informing CVS of these changes is... not easy", what do you mean? How would resyncing to head be more difficult if one has learned better practices or understands Drupal better?
Resyncing HEAD
Resyncing HEAD is as simple as copying the latest code from your last branch (say 6--1) in to HEAD (overwriting whatever is in HEAD originally) and committing it. Then you can create your next branch from HEAD (7--1) and continue work in the branch. "Resyncing" simply means copy/pasting your latest code in so you can start from that point in your new branch.
Lullabot loves you
Learn Drupal online at Drupalize.me
That isn't correct. You
That isn't correct. You need to use the proper CVS commands. You can't just copy/paste as you suggest.
See http://drupal.org/handbook/cvs/quickstart for a great explanation of what to do.
Sure you can. You can copy
Sure you can. You can copy the contents of a file and paste it right into the HEAD version of the file and commit. You can also make a diff and then apply it, which is easier with multiple files and a better recommendation. Either way it is simple to update the code in HEAD. The methods to do it need to be covered in detail obviously, but my point was that you don't have to do crazy things to get your latest code into HEAD.
Lullabot loves you
Learn Drupal online at Drupalize.me
hmm
Add1sun,
Will a diff remove existing files and folders if they no longer exist? If so ++ for this method. Basic level devs NEED to understand diff and patch, so if we can focus on a method that depends on that, then that's a solution in my opinion, to the "obtuse construct of confusion" problem. That's a very straight forward way w/o needing to learn all the extra cvs commands (rm, add, whatever else you can come up with). Not that those commands are difficult, but they present a problem in that, new users feel blind doing this work... it's sort of like floundering in the dark to get through a room full of crap and you've never seen it with the lights on. Eventually you'll get through the room, but you've knocked crap over and made new messes to figure out how to get around next time you walk through the room. Chances are you'll get around to re-organizing the crap, and you'll know your way through the room, but the point is you made a few messes before you memorized where everything was.
That's the best analogy I can come up with... but as I said, if cvs diff can be utilized in such a way as to simplify the developers experience... let's document the crap out of a strategy that includes that, and make this happen.
Eclipse
Diffing and patching are not
Diffing and patching are not CVS tools. They make it easy to move your file changes around (and yes adding new files) but you still must use rm, add and commit to tell CVS about those changes. I think that the blindness factor comes form the fact that these "extra" commands are not used often and the documentation on them is probably not as thorough in terms of real examples to make newbies feel comfortable with them. Frankly I have hardly ever needed to use rm and add, so the 80-90% use case is a simple change to existing files and commit.
Lullabot loves you
Learn Drupal online at Drupalize.me
Simple answer
It depends on how the diff is created for the patch command. If the diff is created with CVS then yes, the delete, additions should happen correctly. However the -dP switch for the cvs update will delete and prune the files for you and of course cvs update will add the new files as well.
clean HEAD
I still do not know what is wrong with making a new branch from a clean HEAD. I lose the history. OK. what else?
RE: clean HEAD
I'm not sure what you mean, do you mean a HEAD where you've deleted everything and then add your modules again? You don't really loose history, you just create work for yourself.
I can see a module maintainer creating a project, and immediately creating a branch and working in the branch. You create the DRUPAL-6--1 from HEAD and your create DRUPAL-7--1 from HEAD but your releases are created with the Drupal branch tags. This makes a lot of sense for module maintainers and keeps HEAD clean for Drupal major version branching purposes only.
work?
I do not see where is the work in it, so I try to I explain it better..
question about dev releases
I agree that option 3 (as detailed in http://groups.drupal.org/node/14944#comment-50560) seems the easiest and most natural.
I would describe that as 'always work and commit in a named branch, don't branch from a branch'.
The one problem I have with that though is dev releases. I'm a newbie though, so please correct me if I'm wrong.
Right now, let's say I have a DRUPAL-6--1 branch, and a semi-stable release at DRUPAL-6--1-1, but I'm still working on the branch and making changes, as expected.
I also have a dev release named on that branch, so I get twice-daily releases as 6.x-1.x-dev. So let's say I have a bug reported, and I fix it and commit it to my drupal-6--1 branch, but I'm not ready to tag a new release for it, so I need people to test. They can't really test until the build scripts cut a new 6.x-1.x-dev, right? So if it takes a few iterations to squash, it may take days, as we are either at the mercy of the 12 hour build cycle, or I have to toss custom tarballs around.
Or should I tag the incremental changes as a new release, like DRUPAL-6--1-2-BETA[integer] until it's good, then tag it DRUPAL-6--1-2?
hmmm, maybe answered my own question.
Testers can probably use CVS and/or apply patches
Anyone testing your module where you need low latency turn-around on the results is probably comfortable just applying a patch from an issue, or checking out the end of the DRUPAL-6--1 branch from CVS. Generally, no, I don't recommend cutting new alpha/beta releases on every incremental change on the off chance that someone's going to test it. Way too much noise for your users. If you have a group of people willing to help test your module (lucky you!), just encourage them to get setup to use CVS and/or apply patches. You'll all be better of in the long run.
oh, I think I get it. I
oh, I think I get it. I should ask them to just do a 'cvs co -r DRUPAL-6--1' or similar. I'll eventually learn how to make, distribute and apply patches, but I'm just not there yet.
patches
Yup, you got it right. Patching is not hard, especially if you're using CVS. See:
http://drupal.org/patch
http://drupal.org/patch/create
...
Patches aren't that scary!
Patches seem a lot more daunting than they actually are! All they are is a file that shows pieces of code removed and pieces of code added in comparison to the original. If you want to try it out, there is a really short and easy to follow step-by-step in the "Crash course" section of this blog post http://affinitybridge.com/blog/patch-review-session-drupal-7-core from when we learned to do patch reviews at work. If you can use command line, you can do it no problem!