I don't see anything wrong with this code. In fact, I tested it on the server using the same user account as the one that is running CCNet (thinking it might have to do with a permission issue). The test told me that the folder was a SVN working folder. So no progress there.
Here are some threads we may explore: * As you might remember from earlier in this message thread, I mentionned that the "FOLDER is not a svn working folder" warning only came when the interval trigger is processed and NOT when I forced a build using the trigger. Why is the warning not present at all times? Because of a simple code path difference? Because the function returns intermittently True (when forcing a build) or False (when the interval trigger is processed) due to a weird bug? * On our CCNet server, we have about 75 projects that are all using individual queues (the default setup) and are using an interval trigger set to 30 seconds. Our SVN server is also hosted on the same machine. Could it be that there are concurrency issues with parallel queues? Is 75 queues too much of a strain for a small-business server? Remember that there seems to be a large quantity (possibly all) of our project that express the warning in the server log... * I am using Visual Studio 2008 (with .Net 3.5) to build your example code. The "System" assembly automatically added as a reference is v2.0.50727. It is this assembly that contains the Directory class. Could it be that CCNet is either built with an older Visual Studio or references an older version of the System assembly? Maybe this older version of the assembly has an issue with paths on Windows Server 2003 (our server is running under Server 2003)? Thanks for any info! >On Jun 30, 2:36 am, Ruben Willems <[email protected]> wrote: > Hi > > the code already looks for _svn also ;-) > this is the function, I added the log.Debug recently, so that statement is > not included in the SP1 release > > private bool WorkingFolderIsKnownAsSvnWorkingFolder(string > workingDirectory) > { > Log.Debug("Checking if {0} is a svn working folder", > workingDirectory); > > if (!Directory.Exists(workingDirectory)) > return false; > > return Directory.GetDirectories(workingDirectory, ".svn").Length > != 0 || > Directory.GetDirectories(workingDirectory, "_svn").Length > != 0; > } > > any idea what could be wrong here? > > with kind regards > Ruben Willems > > On Mon, Jun 29, 2009 at 5:28 PM, Yop83 <[email protected]> wrote: > > > Sorry for the delay, I just came back from vacation :) > > > So, I ran your snippet of code and got, as you expected: > > "True > > 1" > > > I guess this doesn't help very much. > > > On a side note, I would like to point out that in certain cases, the > > SVN folder can be named "_svn" and not ".svn". > > This is an option (some would say "hack") that has been put into SVN > > to work around a stupid bug in Visual Studio .Net 2003 regarding > > folders that start with a "." and web projects. > > > This option is supported by the command-line client. > > More info: > >http://svn.collab.net/repos/svn/trunk/notes/asp-dot-net-hack.txt > > > This option is also supported in TortoiseSVN. > > More info: > >http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.... > > (read the "Use _svn instead of .svn directories" section) > > > So, if the current "SVN working copy detection" code is limited to > > only looking for a ".svn" folder, you should expand it so it also > > looks for "_svn" folders. > > > Thanks, > > And don't hesitate to send me any other tests that might help debug > > the "cleanup" situation. > > > >On Jun 25, 2:47 am, Ruben Willems <[email protected]> wrote: > > > Hi Yop > > > > can you infome me what the outcome of the program is I wrote in the mail? > > > This should help us to pinpoint the problem. > > > > with kind regards > > > Ruben Willems > > > > On Mon, Jun 22, 2009 at 6:16 PM, Yop83 <[email protected]> wrote: > > > > > I am indeed running 1.4.4 SP1. > > > > I double-checked for the warning and I found it. > > > > I missed it the first time around because of the fact that it is NOT > > > > present when a build is forced via the dashboard (I was testing that > > > > way). > > > > The warning is present when the interval trigger is run, though. > > > > > Here is the output of an non-forced integration (the warning is on the > > > > second line): > > > > "2009-06-22 11:58:02,246 [Aggregates - Release 1.0:INFO] Project: > > > > 'Aggregates - Release 1.0' is first in queue: 'Aggregates - Release > > > > 1.0' and shall start integration. > > > > 2009-06-22 11:58:02,293 [Aggregates - Release 1.0:WARN] "D:\Build > > > > directory\Aggregates" is not a svn working folder > > > > 2009-06-22 11:58:02,387 [Aggregates - Release 1.0:DEBUG] Starting > > > > process [svn] in working directory [D:\Build directory\Aggregates] > > > > with arguments [loghttps:// > > svn.mycompany.com/svn/Aggregates/Release-1.0 > > > > -r > > > > <https://svn.mycompany.com/svn/Aggregates/Release-1.0%0A-r>"{2009-06-15T15:11:16Z}:{2009-06-22T15:58:02Z}" > > --verbose --xml -- > > > > non-interactive --no-auth-cache] > > > > 2009-06-22 11:58:02,653 [1820:DEBUG] [Aggregates - Release 1.0 svn] <? > > > > xml version="1.0"?> > > > > 2009-06-22 11:58:02,653 [1820:DEBUG] [Aggregates - Release 1.0 svn] > > > > <log> > > > > 2009-06-22 11:58:02,653 [1820:DEBUG] [Aggregates - Release 1.0 svn] </ > > > > log> > > > > 2009-06-22 11:58:02,856 [Aggregates - Release 1.0:DEBUG] No > > > > <logentry>s found under <log>. > > > > 2009-06-22 11:58:02,856 [Aggregates - Release 1.0:INFO] No > > > > modifications detected." > > > > > Obviously, the warning is a false positive because Subversion is able > > > > to tell that there is no modifications (meaning that my working copy > > > > is up-to-date, which it is). > > > > A quick look in that folder confirms that there is a ".svn" folder. > > > > Also, note that CCNet did the initial check-out of that working copy. > > > > > While checking the logs, I checked out the logs for our other > > > > projects: most, if not all, also exhibit this warning. > > > > Maybe there is something wrong with my configs after all? > > > > > Could it be that the missing trailing slash in the directory string > > > > ("D:\Build directory\Aggregates") could cause this warning? > > > > Also, I cleaned-up the paths in my examples (to remove our company > > > > name). The real path contains 102 characters. > > > > Could the length of the path be a source of issues? > > > > > Thanks. > > > > > > On Jun 19, 5:49 am, Ruben Willems <[email protected]> wrote: > > > > > Hi > > > > > > are you sure that you're running SP1 on the build server, > > > > > because there is a log statement : > > > > > Util.Log.Warning(string.Format("{0} is not a svn working folder", > > > > wd)); > > > > > > so when the svn is not run, this should be in the log. > > > > > > can you double check this? > > > > > > with kind regards > > > > > Ruben Willems > > > > > > On Fri, Jun 19, 2009 at 9:45 AM, Ruben Willems < > > [email protected] > > > > >wrote: > > > > > > > Hi > > > > > > > your config looks ok :-( > > > > > > the only thing preventing the cleanup / revert from running is the > > > > > > following : > > > > > > the code checks that the working folder has a subfolder .svn or > > _svn > > > > > > if not found, do no execute > > > > > > > now comes the trick : which folder is ccnet checking? > > > > > > > I'll add more debug.log statements in the code, so in a future > > version > > > > I > > > > > > know what ccnet is doing where > > > > > > > if you view the project configuration via the validator / dashboard > > / > > > > > > project configuration, > > > > > > which folder do you see in the working directory IN the source > > control > > > > > > block? > > > > > > > with kind regards > > > > > > Ruben Willems > > > > > > > On Thu, Jun 18, 2009 at 8:58 PM, Yop83 <[email protected]> > > > > wrote: > > > > > > >> I uploaded the project config here: > > >http://www.mediafire.com/?sharekey=14cae1bed568604b4c17ca8801618ef7e0. > > > > .. > > > > > >> (The file is called "Aggregates.xml") > > > > > > >> We have multiple project files on our instance of CCNet, so we are > > > > > >> using <cb:include href="myProject.xml"> tags in the main > > ccnet.config > > > > > >> file. > > > > > >> That is why I did not post it: all of the logic (except a couple > > of > > > > > >> variables declaration) is done in the project config file. > > > > > > >> I hope this file can answer your questions. > > > > > >> If you need more info, don't hesitate. > > > > > > >> > On Jun 15, 2:31 pm, Ruben Willems <[email protected]> > > wrote: > > > > > >> > Hi > > > > > > >> > can you post your ccnet.config of the involved project? > > > > > >> > I'm intrested in the following : > > > > > >> > ° do you have a working folder set at the project level ? > > > > > >> > ° your svn section > > > > > > >> > with kind regards > > > > > >> > Ruben Willems > > > > > > >> > On Mon, Jun 15, 2009 at 5:54 PM, Yop83 <[email protected] > > > > > wrote: > > > > > > >> > > I'm using CCNet 1.4.4 SP1 (not a clean install, but an > > update). > > > > > > >> > > A project got stuck in the "exception" state recently because > > the > > > > > >> > > working copy was locked. This was a perfect opportunity for me > > to > > > > add > > > > > >> > > the new <cleanUp>true</cleanup> tag in the source control > > block of > > > > > >> > > that project. > > > > > > >> > > Of course it wasn't that easy... > > > > > > >> > > 1. I added the <cleanUp>true</cleanup> under the sourcecontrol > > > > block > > > > > >> > > of the affected project. > > > > > > >> > > 2. I insured the configuration was updated (by going in the > > > > "Project > > > > > >> > > Configuration" tag of the web dashboard and seeing that the > > tag is > > > > > >> > > correctly set to true). > > > > > > >> > > 3. I forced a build using the web dashboard. > > > > > > >> > > EXPECTED RESULTS: > > > > > >> > > 4. The build succeeds because of the cleanup command is run > > > > against > > > > > >> > > the working directory. > > > > > > >> > > ACTUAL RESULTS: > > > > > >> > > 4. The build still fails with the "working copy locked" error. > > No > > > > > >> > > changes. > > > > > > >> > > SERVER LOG: > > > > > >> > > Here is the server log related to the force build. As you will > > > > see, > > > > > >> > > there is no mention of the cleanup command in the SVN > > arguments: > > > > > >> > > "2009-06-15 11:06:49,658 [Aggregates - Release 1.0:INFO] > > Building: > > > > > >> > > Dashboard triggered a build (ForceBuild) > > > > > >> > > 2009-06-15 11:06:49,658 [Aggregates - Release 1.0:DEBUG] > > Starting > > > > > >> > > process [svn] in working directory [D:\Build > > directory\Aggregates] > > > > > >> > > with arguments [update "D:\Build directory\Aggregates" --non- > > > > > >> > > interactive --no-auth-cache] > > > > > >> > > 2009-06-15 11:06:49,705 [17060:DEBUG] [Aggregates - Release > > 1.0 > > > > svn] > > > > > >> > > svn: Working copy 'D:\Build directory\Aggregates' locked > > > > > >> > > 2009-06-15 11:06:49,720 [17060:DEBUG] [Aggregates - Release > > 1.0 > > > > svn] > > > > > >> > > svn: run 'svn cleanup' to remove locks (type 'svn help > > cleanup' > > > > for > > > > > >> > > details) > > > > > >> > > 2009-06-15 11:06:50,033 [Aggregates - Release 1.0:INFO] > > > > Integration > > > > > >> > > complete: Exception - 15/06/2009 11:06:49 AM" > > > > > > >> > > CONFIGURATION OF OUR SERVER: > > > > > >> > > CCNet 1.4.4 SP1 > > > > > >> > > SVN 1.6.2
