Bryan,
On Thu, 2006-02-16 at 19:50 -0800, Nikolay Molchanov wrote:
1. Preview.
Each transaction should have a preview mode, which allows to see what will
happen
during transaction, but without any changes in developer's and integration
areas.
What do you mean by a transaction here?
I mean something like TeamWare's 'bringover -n', 'putback -n', ws_undo
-n' do.
It's like 'make -n' - print what will happen, but don't make changes.
Most tools have the equivalent
of a "status" command already, which tells you everything you need to
know about changes that you've made within your local working copy.
This is just one part of the "preview". But it does not tell what will
happen during the real transaction.
What does this "status" command show, if I did not make any changes?
Does it compare my development area with any other specified area?
This, together with a "diff" command, essentially acts as a preview of
what a commit will contain.
For "updated" files "diff" is ok, though it is too much in some cases
(sometimes I would
prefer to see only the list of deltas with comments, but not the
contextual diffs). Also
there should be information about removed and renamed files.
For the other major transactional operations, push and pull, Mercurial
provides "incoming" (what would a "pull" bring in?) and "outgoing" (what
would a "push" send out?) commands.
That's exactly what I mean saying "preview".
2. Atomic transaction.
Each transaction should be atomic, which means it should lock the necessary
part of
the integration area.
All DSCMs that I know of lock a repository during a commit.
Good.
It is also interesting what is locked? The whole area? Only the
directories that
will be modified? Ideally it should be a property of the target
"workspace" (IMO).
Ideally the lock should "disappear" if the transaction was interrupted
in any way (system reboot, kill -9, lost connection - whatever).
This is next to impossible to do in the presence of NFS, which is an
exceptionally common use case (nobody trusts POSIX locks to be turned on
or work over NFS, so people use lock directories or symlinks instead,
where the semantics of creation are well defined and usually work). The
best you can really hope for there is "pid X on host Y has the repo
locked".
Yes, but there is a way to release this lock in case a timeout happened.
We have implemented this solution in an experimental version of TeamWare,
and verified that it works great, but unfortunately this version was not
shipped :-)
3. Undo
There should be an easy way to undo a "wrong" transaction. Ideally there
should be a
way to undo all transactions, one by one, but at least the last one.
Mercurial has an "undo" command that rolls back the last transaction.
What this means is that if a "pull" brings in 4 changesets in a single
transaction, an undo that immediately follows will make them all go
away.
Very good.
You can make history prior to the last transaction disappear using the
"clone -r" (built in) or "strip" (available as part of the mq extension)
commands. The strip command actually saves a "bundle" of the changes
that it removes from the repository, so if you decide you stripped the
wrong changes, you can reapply them.
In our practice the ability to remove the history is used very rare (~
once in 2 years),
but I agree that in some cases it is useful.
4. Filemerge
There should be a comfortable tool to do a 3-way merge (parent, child,
ancestor).
Something like filemerge in TeamWare.
Most DSCMs punt to an external tool for this, and let you plug in
whatever tool you personally prefer. It's been years since I've used
Teamware, but I think that almost any of the modern free merge tools is
likely to be quite a bit better than my admittedly fuzzy recollection of
Teamware's filemerge tool.
My point is that this tool should be included, and it should be at least
not
worse than TeamWare filemerge :-), and integrated with "resolve" function.
Some DSCMs do a better job at automated merges than others. Bazaar-NG
uses an SCCS-like weave to provide history-sensitive automated merges.
Good. But it is always important to be able to review the merged conflicts,
and to change the resolution if necessary.
This merge machinery has been ported to run under Mercurial, too, but
it's not yet available by default. I'd expect it to be a bit more work
to port it to Monotone, but it shouldn't be hard in that case, either.
There's also been quite a bit of quasi-theoretical work in the free DSCM
community on automated history-sensitive merging. None of it has really
seen practical implementation yet, but some of the approaches appear to
show promise.
Yes, I agree, there is a lot of room for improvement in automated
history-sensitive merging.
But there should be interactive tools as well, at least not worse than
in TeamWare.
Thanks,
Nik
_______________________________________________
tools-discuss mailing list
[email protected]
