| GyrosGeier | hi | 21:40 |
|---|---|---|
| GyrosGeier | I have an automated build in Jenkins that requires a branch to be merged to succeed | 21:40 |
| GyrosGeier | in that branch are two new files | 21:40 |
| GyrosGeier | when the next build starts, bzr pull --overwrite is run | 21:41 |
| GyrosGeier | which rolls back all the changes, but leaves the files | 21:41 |
| GyrosGeier | which leads to a conflict when redoing the merge | 21:41 |
| GyrosGeier | is there a better way to do this? | 21:41 |
| GyrosGeier | http://ci.kicad-pcb.org/job/kicad-windows-msvc/cpu=x86,label=windows/lastBuild/console is the build log | 21:42 |
| fullermd | Are you committing the merge, or just running on the dirty WT? | 21:43 |
| GyrosGeier | just the dirty tree | 21:44 |
| fullermd | You probably want to run a 'revert' at the end (or before the pull at the start of the next one). | 21:44 |
| GyrosGeier | I can easily create a commit from that, but the build process looks at the bzr id and creates a version string from that | 21:44 |
| GyrosGeier | ah | 21:44 |
| GyrosGeier | so revert before pull should work? | 21:45 |
| fullermd | Or commit the merge (pull --overwrite will remove the files, as they're no longer versioned in the new target), but that's probably just an extra dance for no reason. | 21:45 |
| fullermd | Yeah. pull --overwrite _does_ discard WT changes, but it isn't going to delete a file the pre-pull HEAD didn't know anything about. | 21:45 |
| fullermd | But revert knows the file was created by the merge, so it'll remove it. | 21:45 |
| GyrosGeier | ah | 21:46 |
| GyrosGeier | right now I do pull, then revert | 21:46 |
| * GyrosGeier checks if Jenkins can be taught to revert first | 21:46 | |
| fullermd | There's also a clean-tree command that deletes unknown files; that might be something to look at too. | 21:46 |
| GyrosGeier | ah | 21:46 |
| GyrosGeier | before the merge | 21:47 |
| GyrosGeier | that is a good idea in any case, because I copy in lots of stuff from other builds | 21:47 |
| fullermd | A hardcore option would be something like "bzr remove-tree ; rm -rf * (and maybe .something depending on your tree) ; bzr co ." to completely wipe the slate, but that's pretty drastic and dangerous; one little slip, and... | 21:48 |
| GyrosGeier | well, the box is a VM with no persistent state | 21:48 |
| GyrosGeier | interesting | 21:49 |
| fullermd | Well, you could blow things completely away and do a fresh 'branch' on each run. That would be the cleanest. | 21:49 |
| GyrosGeier | now the extra files are listed with "-D" instead of "- " in the pull output | 21:49 |
| fullermd | Depending on where the source branches are network-wise, that may be Obviously Right, or expensive enough to be questionable. | 21:49 |
| GyrosGeier | the source is on lp, and takes a few minutes to copy | 21:50 |
| GyrosGeier | I'd rather avoid that | 21:50 |
| fullermd | But you could 2-step it with a local cache that you just use as a branch 'pull' source, and then branch from that to a temp loc to do your tests. | 21:50 |
| GyrosGeier | http://ci.kicad-pcb.org/job/kicad-windows-msvc/cpu=x86,label=windows/55/console | 21:50 |
| GyrosGeier | does that look good? | 21:50 |
| GyrosGeier | well, that would require Jenkins to maintain a local cache | 21:50 |
| GyrosGeier | it starts every job on the first free machine it finds | 21:51 |
| GyrosGeier | and might run two jobs in parallel on the same machine | 21:51 |
| GyrosGeier | that is a synchronisation nightmare | 21:51 |
| GyrosGeier | btw | 21:51 |
| GyrosGeier | since I'm here anyway | 21:52 |
| GyrosGeier | is there a good way to maintain a stack of patches on top of another branch? | 21:52 |
| GyrosGeier | and forcibly push the new branch state to LP | 21:52 |
| GyrosGeier | use case is that I maintain a branch containing the necessary patches to make the program build under Windows, and quite often parts of my patches are accepted and sometimes reformatted | 21:53 |
| fullermd | Mmm. You probably do want to try and push the revert to before the pull. In that case it seems to work right since the pull found nothing to do, but if it did, it woulda thrown away the WT state, so wouldn't know to delete files from a previously pending merge. | 21:53 |
| GyrosGeier | hmm | 21:54 |
| fullermd | Or do the clean-tree afterward. | 21:54 |
| GyrosGeier | that's the Jenkins bzr plugin doing that | 21:54 |
| GyrosGeier | the only thing I do manually is the merge | 21:54 |
| GyrosGeier | so I can place the clean-tree right before that | 21:54 |
| fullermd | There was once a 'pipeline' (I think that's what it was called) extension, that did sorta a stack of branches on top of an existing one. | 21:55 |
| fullermd | Sorta a branch-queue instead of a patch-queue. | 21:55 |
| fullermd | But I suspect it'd old enough to not work with current bzr. | 21:55 |
| GyrosGeier | hm | 21:55 |
| GyrosGeier | is there a better workflow for what I need? | 21:55 |
| GyrosGeier | (provide something that is mergeable to the autobuilder, and change that regularly when the base tree changes) | 21:56 |
| GyrosGeier | in a git workflow I'd rebase my branch, and force-push it | 21:56 |
| fullermd | "loom" was another one, that implemented a patch queue. | 21:57 |
| fullermd | There is a 'rebase' plugin. I understand it's not _quite_ the same as git's rebase, but it may be close enough. | 21:57 |
| GyrosGeier | so far, I've been going to the LP website, deleted the branch, then recreated it using bzr, pulled that into git, rebased my changes on top, and pushed the changes from git via the bzr plugin | 21:58 |
| GyrosGeier | but that is really cumbersome | 21:58 |
| GyrosGeier | LP uses something internal to determine whether two commits are the same | 21:59 |
| fullermd | Oh, it'll use the commit-id. | 22:00 |
| fullermd | But you can push --overwrite if necessary. | 22:01 |
| GyrosGeier | ah okay | 22:01 |
| GyrosGeier | I got an exception once when I tried that | 22:01 |
| fullermd | There's a branch config option that can rejected it. I don't think it should be set unless you set it, but if you can write the branch, you can unset it. | 22:03 |
| fullermd | "can rejected it"? What the heck? I haven't had THAT much fun today... | 22:04 |
| * GyrosGeier is already on his second beer | 22:12 | |
| fullermd | I've still got another hour or two of putzing with systems planned before getting there. | 22:17 |
| GyrosGeier | you should get a continuous integration system | 22:19 |
| GyrosGeier | when I want to stop working I start a matrix build of all configurations on all platforms | 22:20 |
| GyrosGeier | and wait for it to finish | 22:20 |
| fullermd | The pump broke. Made a huge mess. | 22:20 |
| GyrosGeier | ah | 22:21 |
| GyrosGeier | so actual good reason | 22:21 |
| fullermd | No, I meant the "continuous integration" system for the beer ;> | 22:26 |
| GyrosGeier | ah | 22:26 |
| GyrosGeier | the party at the upstairs neighbours' is getting out of hand | 22:27 |
| GyrosGeier | I should get a beer and go there | 22:27 |
| fullermd | That sounds like it would increase the outofhandedness. | 22:27 |
| GyrosGeier | yes | 22:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!