Update on Beyond Compare inside Team Build and why I’m starting to hate TFS

In the past few days, and nights, I’ve learned a few things. Most are bummers, but there is light at the end of the tunnel. This is what I feel our build process was like for the past few days, but I think we’re doing much better now and things are actually working. (Cross your fingers)

I’ve tried a few approaches yesterday and here is what I’ve found.

Deploying via Ftp

Initially, I tried to deploy to our servers via FTP. This appears to work well, but the timestamps are all adjusted by the GMT offset. In our case, the files end up on the server looking like they were edited 6 hours in the future. This makes every single file appear different on the next sync since none of the time stamps match. Apparently this is by design from Microsoft. What a bummer. Running the development server on GMT will cause the timestamps in the database on that server to also be off. This option is out.

Deploying via file share

Again, this appears to work well. The first time everything goes. We change a single file and the log sees that only one file has changed, but doesn’t move it. Doh! They come out of TFS as read-only, and copying to a file share will carry over those file attributes. No problem.  

attrib -r \\myServer\myShare\myApp\*.*

Nope! You can’t run attrib on a network share. It has to be a physical disk.

OK. Well I’ll just attrib -r the source files in the build’s working directory. Great! That worked. Let’s try it again. Doh!

Unable to perform the get operation because it is writable.

Miedo

You’re kidding me! Grr…OK! Fine! I’ll attrib +r after I push. Nope! Not every file in the source directory is suppose to be read only and some of them cannot be read only. AHHH!

Oh yes! Beyond Compare has an attrib -r command in the scripting reference.

ATTRIB
Usage: attrib (+|-) [(+|-) <...>]

Sets (+) or clears (-) the DOS file attributes in the current selection. An attribute set can include archive (a), system (s), hidden (h), and read only (r) attributes. Windows only implementation: Linux version will not recognize ATTRIB.

Sound great right?….that doesn’t work. Even on simple unit test this doesn’t work. I’m at my wit’s end now. There is one more thing to try. There is one more command in the Beyond Compare script reference that might be able to help.

OPTION
Usage:
option stop-on-error
option confirm:(prompt|yes-to-all|no-to-all)

Adjusts script processing options.
· stop-on-error makes the script watch for various error conditions, including file operation errors, and, when one occurs, prompts the user before continuing.
· confirm can use prompt, yes-to-all, or no-to-all to handle confirmation dialogs that occur due to file operations. By default, prompt is used.

Let’s hope this works. I’ll put it right before the sync, cross our fingers and run it through some tests.

It WORKS! Or it appears to so far. Hopefully.

The files on the server still carry the read only flag. That’s not ideal for us, but it will have to do for now.

7 Comments so far

  1. Bill Sorensen on February 2nd, 2009

    I’d let BeyondCompare know if you think you found a bug – they’re very responsive in my experience.

    You can use the /overwrite switch on the tf get command to overwrite writeable files that are not checked out. See http://msdn.microsoft.com/en-us/library/fx7sdeyf.aspx

    I’d suggest checking out NAnt – it may be exactly what you need. You can script a lot of things with that. http://nant.sourceforge.net/ It has an attrib command to change file attributes.

  2. Craig Peterson on February 2nd, 2009

    Based on your previous blog post, I’d guess using the “attrib” command in Beyond Compare’s script is failing because you haven’t done a “select” command first, so it doesn’t know what files to change.

    After your sync command add these two lines:

    select rt
    attrib -r

    If you did want to try deploying via FTP again, you can adjust what timezone BC thinks the server is using in the “FTP Profiles” dialog on the Tools menu. Try switching it explicitly to GMT or UTC.

  3. mark on February 2nd, 2009

    @Bill I’ll have to see if some step of the Team Build will accept that parameter. We aren’t calling the Get command directly, so hopefully we can send that /overwrite parameter in somehow.

    MSBuild has similar tasks to NAnt, but you don’t get the out of the box. You have to us the community tasks and the SDC tasks.

  4. mark on February 2nd, 2009

    @Craig Thanks! I bet that is the same problem I’m having with the TOUCH command. I’m going to give setting the server timezone manually. Hopefully that profile will get used when connecting to the server via script. That sounds very promising.

  5. mark on February 2nd, 2009

    No luck. :( When I set the timezone in Beyond Compare to the timezone I know the server is in, the times are off in 6 hours (our GMT adjustment) the other direction.

  6. Craig Peterson on February 4th, 2009

    Have you tried setting it to GMT or UTC instead of the actual server’s timezone? Many FTP servers expect and return UTC dates and I think that would give the behavior you’re describing. if that doesn’t work and you want to keep pursuing this I’d suggest emailing support@scootersoftware.com or posting in the forums again so the regular support guys can have see this too. On a related note, and in case you didn’t see it, the next release will have exit codes for scripts.

  7. mark on February 4th, 2009

    @Craig That actually does work, but then all the uses of our current system time in applications and databases would have to be offset too. While it would ideal to do that based on user current timezone, this is an internal app and we are assured everyone is in the same timezone.

    I did post something in the forums (http://www.scootersoftware.com/vbulletin/showthread.php?t=3277), but didn’t hear anything. I probably should have started a new thread instead of attaching to this one.

    That’s great about the exit codes. That will help out tons.

    For now, we’re deploying via UNC share which works fine; however not ideal.

Leave a Reply