Hi

I updated the source, so if you can grab the latest build at
http://ccnetlive.thoughtworks.com/CCNet-builds/1.4.4/1.4.4.95
or higher, and let me know if it works, I would be gratefull.



as for the getmodifications : I am no svn expert,
but if the working copy is locked, I do not know what the getmods will
return.
I would expect it to run, because the command is log url <fromdate>
<tilldate>
but like I saidj, I'm no svn expert.


with kind regards
Ruben Willems



On Wed, Jul 1, 2009 at 7:18 AM, Ruben Willems <[email protected]>wrote:

> Hi
>
> looking into it, I was planning on doing a SP2 this weekend,
> but really want this bug squashed.
> I'll try to update the source today, need to check the unit tests.
>
> as for the getmodifications : that's a good question,
> will need to delve into it
>
>
> with kind regards
> Ruben Willems
>
>
> On Wed, Jul 1, 2009 at 1:30 AM, Yop83 <[email protected]> wrote:
>
>>
>> I just downloaded CCNet 1.4.4 SP1's source code to check things out by
>> myself...
>>
>> I think I found a likely culprit:
>> at \project\core\sourcecontrol\Svn.cs:103, in the GetModifications()
>> method.
>>
>> The line reads like that:
>> string wd = StringUtil.AutoDoubleQuoteString(Path.GetFullPath
>> (to.BaseFromWorkingDirectory(WorkingDirectory)));
>>
>>
>> The resulting "wd" variable will contain a double quote character at
>> the beginning and at the end of it.
>>
>> This is what makes the WorkingFolderIsKnownAsSvnWorkingFolder() method
>> fail!
>> The method fails at the Directory.Exists() check. I tested it with a
>> double-quoted string and got a fail.
>>
>> The AutoDoubleQuoteString() should not be used for actual work on a
>> directory. I guess it's a simple cut & paste accident :)
>>
>> Rewriting the GetModifications() method should allow the cleanup and
>> revert option to work.
>> This will be great.
>>
>> How soon can you get the fix in?
>> Thanks a lot
>>
>> P.S: This still doesn't explain why the GetModifications() method is
>> not called when Forcing a build. Is there a specific reason for that?
>>
>> >On Jun 30, 6:58 pm, Yop83 <[email protected]> wrote:
>> > 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.
>> >
>> > ...
>> >
>> > read more »
>
>
>

Reply via email to