> I don't think keeping patches in a directory makes much sense, just apply > them to the copy of the vendor code in trunk. Subversion keeps track of > what's changed, being a version control system ;)
Some things come to mind: 1. Having a directory of the patches we apply is for people that aren't familiar with the source or history of that code in our repository. For instance, my initial instinct to find the diff was to get trunk and then run a diff across the files outside of SVN to see what was different. I didn't even know the vendor branch existed until poking around after seeing that SVN link. 2. Hopefully, it'd make upgrading our dependencies easier. This is quite subjective, but "blow away directory, copy in new files, apply patches" seems easier to reason about than "put new copy of dependency in SVN, diff the versions and apply diff on top of our patches." Granted I haven't actually tried writing such a script so who's to say. 3. Most damning against the patches as files is that generating those patches could be 'fun'. I'd say "make it a work flow thing" but that just seems like bad form. Though perhaps having an extra step would force us to reconsider if applying a patch downstream is worth it thus lowering the risk of unintentional forkage. 4. Having patches as files should make it easier to reason about what needs to be sent upstream. 5. Git has eaten my soul. I can't stop thinking "REBASE!" being yelled by the "MUNCTIONAL!" guy. Paul Davis
