Very nice program. Comments and usage questions...
Marc Singer
elf at buici.com
Sun Jul 10 20:50:41 UTC 2005
On Sun, Jul 10, 2005 at 09:27:44PM +0100, Mark Williamson wrote:
[deletia]
> The fsck problem looks like it only applies if you're sharing the same object
> database. A clone won't do that in git (AFAIK) but will therefore take up a
> fair bit of space (but disk space is cheap ;-)).
Assumptions like this are, IMHO, unfriendly. Not everyone can afford
to keep up with the disk space explosion. Also, think about what it
takes to update a dozen different development trees from the upstream
feeds.
> I do the following:
> hg pull # gets the latest changes and squirrels them away in .hg/
> hg update -m # gets the changes into my working dir, does the merges
>
> At this point it mentions a load of "merges" that are often files I've not
> touched - it handles these on its own, I only get conflicts on files I've
> actually changed. I've been assuming that a "merge" occurs every time I've
> made a checkin and therefore "branched" the history, so these messages
> nothing to worry about.
So, now you've got changes from the upstream feed intermingled with
your own. All of this still has to be committed, right?
Let's say I've got ten different patch sets for various different
features or drivers. Once I do the update, I've got a vast mess of
changes, some from the upstream feed, and some from fixing conflicts.
Of course, I can determine the differences between my working copy and
the upstream master, but I have to comb out all of my patches again so
that I can distribute them separately.
Frankly, that just isn't worth the time. I'm better off saving the
patches separately and reapplying them to a copy of the latest
upstream.
> > Similarly, I tried something like this with the current repo. I
> > updated to 2.6.11, applied my patch, updated to 2.6.12 with merging
> > and was greeted with a mess of changed files that had nothing to do
> > with my patch.
>
> Does it actually require you to resolve anything, or does it just work?
It was a chaotic mess. Perhaps I tickled a bug.
What I need is for the SCM to apply the upstream changes 'underneath'
my changes. The upstream changes must all be clean when applied to
the tree. My changes may conflict, but I'm prepared to fix them.
I think that BK has this kind of an idea because it allows changesets
from other development lines to merge into the main line as
development proceeds. It also allows development trees to accept
changes from several feeds.
/ SCSI-development-tree \
Linus -> ATAPI-development-tree -> test-tree
\ PXA-development-tree /
In the absence of that, it would be helpful to be able to do this.
# hg pull
# hg update -C REVISION_FOR_NEW_BASELINE
# hg apply-from-revision REVISION_OF_PREVIOUS_PATCH_SET
I update the patchset to build and run.
# hg commit
# hg apply-from-revision REVISION_OF_ANOTHER_PREVIOUS_PATCH_SET
I update this patchset to build and run, and so on.
Cheers.
More information about the Mercurial
mailing list