Fri, 07 Feb 2014 17:28:37 +0100 convert: make subversion revsplit more stable when meeting revisions without @
Mads Kiilerich <madski@unity3d.com> [Fri, 07 Feb 2014 17:28:37 +0100] rev 20419
convert: make subversion revsplit more stable when meeting revisions without @ revsplit would crash for instance if given a subversion string without @ ... and that could somehow happen when playing around with convert.
Thu, 06 Feb 2014 14:57:25 -0800 revset: minor changes adding baseset to revsets
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 14:57:25 -0800] rev 20418
revset: minor changes adding baseset to revsets Changed bits of code to work with baseset implementations.
Thu, 06 Feb 2014 11:37:16 -0800 revset: added __add__ method to baseset class
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 11:37:16 -0800] rev 20417
revset: added __add__ method to baseset class
Thu, 06 Feb 2014 11:33:36 -0800 revset: added docstring to baseset class
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 11:33:36 -0800] rev 20416
revset: added docstring to baseset class
Mon, 10 Feb 2014 00:43:54 +0100 merge: don't overwrite file untracked after remove, abort with 'untracked files' stable
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:43:54 +0100] rev 20415
merge: don't overwrite file untracked after remove, abort with 'untracked files' Merge could overwrite untracked files and cause data loss. Instead we now handle the 'local side removed file and has untracked file instead' case as the 'other side added file that local has untracked' case: FILE: untracked file exists abort: untracked files in working directory differ from files in requested revision It could perhaps make sense to create .orig files when overwriting, either instead of aborting or when overwriting anyway because of force ... but for now we stay consistent with similar cases.
Mon, 10 Feb 2014 00:54:40 +0100 shelve: better (and slightly redundant) test coverage for unshelve conflicts
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:54:40 +0100] rev 20414
shelve: better (and slightly redundant) test coverage for unshelve conflicts
Mon, 10 Feb 2014 00:54:27 +0100 shelve: status messages from unshelve
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:54:27 +0100] rev 20413
shelve: status messages from unshelve It was hard for the user to know what was going on when unshelving - especially if the user had to resolve conflicts and thus got to see the intermediate states. Seeing that pending changes was gone could scare the user, make him panic, and do stuff that really made him lose data. Merging (both when rebasing and with pending changes) also requires some understanding of where in the process you are and what you are merging. To help the user we now show a couple of status messages (when relevant): temporarily committing pending changes (restore with 'hg unshelve --abort') rebasing shelved changes
Mon, 10 Feb 2014 00:54:12 +0100 shelve: be quiet when unshelve pulls from the shelve bundle
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:54:12 +0100] rev 20412
shelve: be quiet when unshelve pulls from the shelve bundle unshelve was quite verbose and it was hard for a user to follow what really was going on. It ended up saying 'added 1 changesets' ... but the user just expected and got pending changes and never saw any changeset. The use of bundles is an implementation detail that we don't have to leak here. Pulling is quite verbose, optimized for pulling many changesets from remote repos - that is not the case here. Instead, set the quiet flag when pulling the bundle - not only when temporarily committing pending changes. The 'finally' restore of ui.quiet is moved to the outer try/finally used for locking.
Mon, 10 Feb 2014 00:53:27 +0100 shelve: add 'changes to' prefix to default shelve message
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:53:27 +0100] rev 20411
shelve: add 'changes to' prefix to default shelve message The shelved changes _could_ perhaps be amended to the parent changeset but it _is_ not the parent changeset. Using the description from the parent changeset is thus wrong and confusing. Instead, add a 'changes to' prefix.
Mon, 10 Feb 2014 00:53:27 +0100 shelve: mention FILE options in help
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:53:27 +0100] rev 20410
shelve: mention FILE options in help Shelve do normally take a list of files or patterns to shelve and the command summary should thus show [FILE]... Note: --delete is a bit special and interpret the parameters as a list of shelve names. This change makes that even less obvious from the help. Too bad - we can't please everyone.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip