just wanna ask for anything new? anything ambiguous?
Hi Christian,
We’ve been able to these replicate issues after some further testing.
The files checked out for the Mercurial were being left as uncommitted files. We had wrongly assumed that the svn switch command would discard these files with the -accept option that we specified. We have now worked out a fix with involves using svn revert on our repository cache before running svn switch.
You can download a new build (version 1.0.0.0.2426) with this fix using the links below:
- Continua CI Server Setup 64-bit
- Continua CI Server Setup 32-bit
- Continua CI Agent Setup 64-bit
- Continua CI Agent Setup 32-bit
oh great. i’ll test it immediately. revert before switch seems to be safe.
until now it seems to work but an event log entries occur which is at least a little bit buggy:
"SVN: Uncommitted changes after switching to revision {0} on url ‘{1}’. "
i cant’ say if this entry is important and who was modifying this. as far as i know the “agent” cannot modify the servers checkout.
keep in mind: before testing, i always reset the repository.
two more things:
- if the build is launched through a trigger, it seems that the switch happens but starting a build manually (using queue and entering branch name or in case of default branch, launching an immediate build) its not switching. well, tortoise properties say, is still the last triggered branch. maybe this will cause unexpected issues?
- looking into the properties of the repository checkout on the server, the svn revision listed here (tortoise tab) is the top most available for this branch but i found at least one file not having the changes of that revision (was changed recently). i can see this because the file is an artifact and it still contains values that were fixed some minutes ago in this branch. so it looks like the branch is marked as being NEWEST but does not having all files updated to NEWEST. for sure, this can only be a symptom of the real issue not yet identified.
First one is as designed, when you manually start a build, we do check for changes and only do the switch if new changes are found. If no new changes are found then the source used is the most recent revision on the branch, which is already in our cache.
Not sure I understand what you mean in your second point (artifact?). When we call switch to branch, we always specify a revision, that revision is the revision of the Change we detected via svn log. If more than one new revision is found then switch to branch will be called once per revision, and then committed to our cache.
well, i’ve merged a change from trunk to a branch. but as i write this, i remember that the trigger did not start because it is was an one file commit and that file is in the exclude pattern of the repository because i commit it during our “deploy” stage. so that would be the reason it was ignored and not available to continua.
this change will only be visible the next time i commit something.
this will bring up the next question. shouldn’t excludes be defined at (repository) trigger level instead of repository level? or both?
because i wan’t ignore builds to be started and not changes to be ignored if i start manually. this wasn’t expected by me.
The new build (version 1.0.0.0.2431) with this fix can be downloaded using the links below:
definitely. however, thank you very much for your effort on solving my problems.