couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Apache Maven/Maven repo (Re: Dependencies in SVN)
Date Tue, 11 Aug 2009 11:23:54 GMT
> 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

Mime
View raw message