http://bugs.grommit.com/show_bug.cgi?id=407
Summary: cdm's branch handling may still confuse people
Product: SCM Migration
Version: unspecified
Platform: All
OS/Version: Solaris 11/Nevada
Status: NEW
Severity: normal
Priority: P3
Component: cdm
AssignedTo: scm-migration-dev at opensolaris.org
ReportedBy: richlowe at richlowe.net
I'm filing this as a catch-all for the branching bits that behave
somewhat surprisingly, either such that they can be fixed, or
documented (or both).
1. We pretend the dirstate is the head of a branch, making the active
list somewhat confusing if you're at a non-head changeset. (it is
truncated at the current working revision)
2. We do not warn the user if they are in a situation where #1,
above, will occur.
3. Backup treats the dirstate as if it's always a branch head, when
deciding if your working copy changed.
4. We may assume in various places that in a merge, the remote parent
is always the second. This isn't true.
The root cause is primarily technical, in that if you are back in
workspace history, there is the possibility of the branch you are on
having more than one head, and no obvious way to guess which head is
the one the user would intend or whether, in fact, the working copy
*should* be treated as a new head (perhaps they're working back in the
history such as to create a new branch, for instance).
The options I see (for the first two in that list) are to error if
they aren't at a head (where a modified working copy is taken as a
head wherever it may occur), to guess a suitable head, perhaps the
tip-most head of the current branch (which would most recent on that
branch).
I suspect that in any case, we should warn the user that we're taking
a guess, or treating any revision other than their current revision as
the head.
--
Configure bugmail: http://bugs.grommit.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
