The validation is using "SVN list" to get a full list of folders in the repository to check if the branch pattern matches at least one branch.
Unfortunately, this is timing out on your repository. We'll investigate if we can using a different method to validate the branch and get a fix out in the next few days.
When the build is run, the specified branch (in the queue branch dialog) or the default branch (if none is specified) is checked out to the relevant workspace folder. We use a repository cache to make this more efficient.
hm ok, i don’t know in detail how you do it right know, but by respecting complex regex maybe something like this will work:
Get first level list: svn list --depth=immediates url://toRepo/Branches
use pattern against the list. if nothing matched, iterate each first level and get the first level of it. if still nothing matches, go one level deeper. currently my/the problem is that you search some kind of alphabetically (where all these many old branches start with something lower than “V” or “H”), so they will be tested against the pattern first and my matching branches at the end, even if they are first level.
so maybe check level wise and not alphabetically / from top to bottom as svn list returns. but however, i trust in you, you will do it
The thing with branches in subversion is that the Branches folder is just a convention, it could be called anything. The regex is used to allow picking out branches, getting the list of branches is not simple because svn doesn’t have a command for this, or a command that takes a regex. We’ll take a look at this next week and see if there is anything we can do to speed it up.
But besides that, when i wanna use one repository for the structure given above, are my settings correct? Because i can’t figure out whats going wrong and how (i think is mercurial) is doing these checkouts locally. If i set up the repository like above, i always have the checkout of the default branch in the server workspace. now if the monitoring matches one of the given branches, where is that checkout on the server placed? sometimes i get strange “merges” which cause in build errors for branches.
well. i’m not a mercurial pro (never used it), so i don’t know if its your problem or a mercurial subversion plugin problem.
It depends on how you are starting the build. When you start a build manually using the single arrow icon, you can specify the repository branch in the dialog that appears. Continua will then build the latest changeset on the specified branch. The double arrow icon runs the build the latest changeset on the default branch for each repository.
If you are using a trigger, then, for most trigger types, Continua will build the latest changeset on the default branch for each repository.
The Repository trigger type allows you to specify which branch or branches trigger the build when a new changeset is detected. In this case, Continua exports the latest changeset which triggered the build which will be in the branch (or one of the branches) specified.
The files are checked out from the root of the branch. For example, if using a Subversion repository called Repo1, you have a file "/branches/branch1/readme.txt" and have specified the branch as "/branches/branch1" when starting the build manually, then you can access the file as $Source.Repo1$/readme.txt
hm, now if use /(Features|Versions)/[^/]+/ as branch pattern, i get the following error message: parsing “Versions)” - Too many )'s. well, if i just use /Versions/[^/]+/ thge validation is nearly instant, so it seems to be ok from the performance point of view.
after saving the repository (as configured in the picture above, continua is doing a checkout of “trunk” (the default branch) to the servers workspace. so far so good.
when queue a build using any branch (e.g. “Versions/1.2.3.4”), i can see a “hg.exe --clone C:\CheckoutOfTrunk”), so i thiink he is cloning it to agent?! but that seems wrong to me because its cloning “Trunk” and not my “Branch”.
so maybe this makes it clearer where my problem is. i am “missing” the checkout of the branch that was queued. and additionally, when someone commits into any branch, the changes seem to be merged into the checked out “Trunk” which will produce build errors (as already described above).
so do i am misunderstanding something or how should this work internally?
There was a typo in my code - which meant that an extra ')' was used in a regex search. I've now fixed this for the next build.
Continua checks your repository for new changesets at the Polling Frequency which is every 60 seconds by default. If it finds any changes on the default branch or any branches which match your branch pattern then each of these changesets are then checked out to the repository cache folder on the server. The repository cache is a Mercurial repository that we use to store all the changesets from all branches. As each changeset is checked out to this folder, the files are then added and changes committed to an associated branch in the Mercurial repository.
When a build is run, this check above is triggered first to ensure we have the latest changes, then the Mercurial repository cache on the server is cloned to a new repository cache on the agent (or changes pulled to an existing repository cache). The agent will then update the agent repository cache folder from the Mercurial repository taking the revision associated with latest changeset on the specified branch of the original Subversion repository.
I hope that makes the process a bit clearer.
I'm not sure why you seem to be getting changes merged between branches as we switch before checking out. We do some further testing today to see if we've missed something.
This build has not had a lot of testing so I’m not posting this as an official update yet (it’s late on Friday) but I wanted to get this out to you. We’ll have an official update out next week.
As far is i could test it right now, it seems to work. Also the merge problem is gone. I noticed that you do a svn switch on the server now. This seems to work. Well because of that, it would be nice to have a “default branch” (even Trunk should still be possible) at configuration level that would override the default of the repository.
So when i am using the repository in different configurations, i can override what happens when clicking “Queue a build immediately”. Otherwise if i want to start a build manully for a branch, i always have to “Queue a build” and correct the branches name. Having a defined preset per configuration here would be great.
Additionally it would be great to have option to deny immediately builds per configuration or they get forbidden if no default branch/pattern is given.
Just one note: If you delete a branch in the repository and create a new one using the same name, then there will be merge issues in the next build of that branch. Don’t know how mercurial is working internally but you can solve this using “Reset” of the corresponding repository.
ok, i have to say, its still not working. The branch switches within one repository are still corrupt. I can verify this because i have a build script that returns the version of an assembly within that branch. After starting some builds in each configuration (for different branches within the same repository) the working on the server still seems to be mixed up because i get the version of a “release branch” displayed in “trunk”. but the version in trunk is already different (higher).
So i can’t rely on the source code that gets compiled when i use one reopsitory for all branches (trunk, versions, features). Thats really really bad. I would prefer this because it makes cloning very easy (just 2 clicks with my setup). Creating a repository for each (single) branch would cause much more work (as already mentioned above) when cloning.
maybe you simply can put all “HG / SVN / …” repository relevant calls to debug log, so i can help figuring out whats going on. Its the only problem that will deny using Continua in production environment
In order to solve this we are going to need as much information as possible about your repository, ie
Repo settings, svn folder structure, branches etc, where in the folder structure the commits were made etc. Ideally if you could provide us with a commit log that shows the commits in question that would be helpful (send to support email, don’t post here).