New actions #14
New actions #14
Conversation
| output = system("bzr missing") | ||
| output = output.strip() | ||
| output_lines = output.split('\n') | ||
| if "Branches are up to date." in output_lines: |
There was a problem hiding this comment.
Lines like this are very brittle. I'm speaking from experience with zest.releaser here. Problems I've seen:
- Suddenly the initial letter 'B' becomes a 'b' in a newer version of bzr (or one of the other ones).
- Someone has a localized shell and bzr nicely renders the message in french/german/dutch/whatever...
I'm not against testing for the string output like you're doing: there's not much else we can do. I've tried looking at exit codes in zest.releaser and that was even worse :-) There are two things we can do:
- At least do a
.lower()before comparing. - Add a short note in the readme for the "cu" command that it is inherently a bit fragile as it depends on the english textual output of the various commands.
There was a problem hiding this comment.
I agree. I've tried to use the most apparently reliable indicators for each command, but my experience with both bzr and hg was some years ago.
Since these commands are alongside the checkoutmanager functionality that exists at present and don't interfere with it otherwise, I propose starting out with something which seems to be acceptable and tweak it as and when issues are discovered.
If there is a more reliable indicator, I'm more than happy to switch to that. For example, I'm currently considering bzr revno for up instead of bzr log -r-1. This should more reliably return the revision number.
There was a problem hiding this comment.
I agree that this new command is separate from the existing ones. So something that's mostly working is fine and we can tweak it later when needed.
So what you have now is fine (apart from adding a .lower()), though you are free to experiment with that "bzr log -r -1" stuff of course :-)
There was a problem hiding this comment.
For bzr I think bzr missing --theirs-only is better.
|
@mauritsvanrees, can you take a quick look?
|
|
@chintal : can you give a ping when you consider the PR to be ready? Then I can have a final look and merge it. |
|
|
||
| @capture_stdout | ||
| def cmd_cu(self): | ||
| output = system("git pull --dry-run") |
There was a problem hiding this comment.
Maybe git fetch? That already gets the code, without updating the working copy.
There was a problem hiding this comment.
cu/in shouldn't be doing anything that changes the local filesystem
|
I added some comments. Seems okay otherwise. Idea: maybe add |
|
"Does it work on windows" is the number one question that springs to my suspicious mind :-) |
|
@reinout I think it's ready to go. |
| @@ -71,6 +71,15 @@ co | |||
| missing | |||
| Print directories that are missing from the config file | |||
|
|
|||
| out | |||
There was a problem hiding this comment.
Weird! So "out" wasn't documented yet? Good catch :-)
|
Thanks for your work! I've released 2.4. Can you check if it works? And review the changelog? https://github.com/reinout/checkoutmanager/blob/master/CHANGES.rst#24-2015-09-09 |
Added actions
inandrev.in(previously
cu)Check for incoming changes before applying them.
Typical usage is to determine which repositories have incoming updates, and to use that information to prevent expected problems by cleaning up necessary trees when
upis run, or by not runningupat that point if it's likely to cause merge conflicts or the like.inshould not change the local filesystem in any way (working copy or repository), given that we don't make any assumptions about the workflow the user wants to use.revPrint the current revision of the working tree. There isn't much use for it when run as a script, but there are use cases for being able to obtain this revision information when used as a module. My immediate use case is to include the revision information of semi-automated test definitions when generating test reports from semi-automated or automated tests. I'm using pysvn to get the revision information for the moment, which works fine, but locks me in to svn.
Implementations notes
Both of these work actions work fine for SVN, and if there are problems or corner cases I'll see them soon enough.
bzr, git, and hg implementations have only been tested on simple repositories with a simple upstream and clean working trees. I think they should still work, but some care may be called for before making use of these actions in production for those version systems.