new user questions
Christopher Li
hg at chrisli.org
Thu Jun 2 13:13:22 UTC 2005
On Wed, Jun 01, 2005 at 09:30:14PM -0700, Matt Mackall wrote:
> On Wed, Jun 01, 2005 at 10:30:25PM -0400, Andrew Thompson wrote:
>
> It's the way it works today, but it's not written in stone. I've been
> trying to come up with a good solution for a while.
>
> And as I'm sitting here, a relatively painless way to efficiently
> track multiple heads occurred to me. Each index entry contains a
> linkrev field. For file revisions, this points back to the changeset.
> For changesets, it points back to itself. If instead it were made to
> point back to the previous head in the log, we'd then have a
> singly-linked list of head revisions (that terminates whenever we find
> something that's the child of something already in the list).
How does this work for this case:
1) You have root node.
2) create three head A0, B0, C0 from root. so C0->B0->A0->NULL
3) alternate check in from C and B head many times. Some the head will be:
C2->B2->C1->B1->C0->B0->A0->NULL?
It seems you still need to go through the whole list to get A?
Unless you want to go update the previous node which break the append only feature.
So what is wrong with adding another field in the change log say the head number?
Then you have yet other head index file points to the latest changelog. The head
index file is grow only. On undo you just update the index back to the the parent
node(p1). And undo track the head file size as well.
>
> The network protocol would need to be tweaked a bit to manage it, but
> only slightly.
>
> This may actually solve a bunch of problems at once:
>
> - checking in something not on the tip
> - needing to resolve during a pull
> - currently no way to merge changes from pull into changes in working
> dir
SourceMania should work with all this. Check my other email in this thread.
>
> So the idea is:
>
> hg merge - pull all branches from remote, but do no resolve
I am glad we are heading the same direction now.
That is the pull stage in SM. Let's call it pull.
> hg checkout [version] - checkout, remember version as parent1 for commit
> hg resolve [version] - attempt to merge given version into working
> directory, defaults to attempting to merge with
> tip
> remember version as parent2 for commit
> not allowed to do a resolve if you haven't
> committed your last one
> hg commit - add a new head with parent1 and parent2
> now what's in our working directory is equal to the new
> head and will be parent1 for the next checkin
Yes, that will be one valid way to do it. In SM it also allow just specify
merge any two heads (A, B) without checkout to working space, then the result
is check in as a child of A, with reference to B.
> This still leaves some loose ends like what are the semantics of a
> checkout when you've already got something in your working directory?
There is many way to deal with it. You can refuse to check out and
ask user to check in the pending changes then merge.
You can also do a auto merge as if the working directory has check
in and merge base on that.
> Maybe we just want to call checkout and resolve "get" and if you've
> got something already, a second get attempts a resolve.
Using second get to resolve is confusing. First get give you warning
some file can't be updated due to pending changes. Then use a resolve
command to resolve that.
Chris
More information about the Mercurial
mailing list