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.html
> (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
>
