On Mon, Dec 16, 2002 at 10:16:39AM -0500, Ben Collins wrote:
> > This merge looks fishy. It seems to be yet another let's throw my CVS
> > repo in merge and backs out Al's work yo get rid of lots of devfs crap.
>
> Quit talking shit. I go through a lot of effort to merge in changes sent
> to Linus' tree into the Linux1394 repo. I don't just dump changes for no
> good reason.
>
> How about pointing out some specifics?
Take a look at the changeset at
http://linus.bkbits.net:8080/linux-2.5/diffs/drivers/ieee1394/dv1394.c@1.15?nav=index.html|src/|src/drivers|src/drivers/ieee1394|hist/drivers/ieee1394/dv1394.c.
Your big BLOB merge basically undoes everything in there.
> Maybe make my job easier by getting me some patches directly.
It was Al's patch, not mine.
> Trying to track two seperate source tree's isn't as easy as you might think.
In fact it's not difficult at all with a proper SCM, a bit of care and the
right attitude. I merge the changes from XFS (and about half a donzend
XFS-related repositories inside SGI that all need proper merging / keeping
in sync) to Linus all the time. And by keeping the changesets (or atomic
commits in SVN terminlogoy) as one patch each, hand-editing as needed when
merge conflicts arrive that works very well, even if I had been away and
the changes for four weeks need merging or as now we're five patchlevels
away from Linus tree (at 2.5.47). I've not lost a single upstream change
with that merge policy yet.
And no, that's no BK advertisment, SGI uses a RCS-based SCM internally and
I use unfied diffs to get it into a staging repository for Linus to pull.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:13 EST