Sharing source control depot between OS

Discussion in 'Parallels Desktop for Mac' started by drd, Dec 25, 2006.

  1. drd

    drd Bit poster

    Messages:
    3
    Hi,

    The main reason I'd like to use Parallels is for x-platform development for OSX and Windows. I have a source controled code depot (using Perforce) on the Mac side, and I've shared it via Shared Folders to the Windows side. When I try to open one of the workspace or project files from VS6 in windows XP (guest os), they do not load. I'm guessing this is an issue specific to vs6 perhaps not being able to open workspaces or projects (.dsw/.dsp) from a network (presumably because it does not want to write pref files there?). I tried mapping the shared folder as a drive thinking this would circumvent the issue, but this did not work. Perhaps I'm not sure what the real issue is. Any ideas? Is something lost in the file system? Is there any way to make a shared folder local on the guest OS side?

    Just to verify, I can open source files individually with no problem, and of course if I run the source control client on the guest side and download the same source to a local folder the projects open fine. But this is far less than ideal. The whole idea being to share the same source depot on the same machine between both OSs and be able to quickly switch between to compile and test (without the hassles and waste of checking in, syncing a second depot, etc).

    Thanks,
    ~D
     
  2. palter

    palter Hunter

    Messages:
    243
    Are the workspace/project files (.dsw/.dsp) binary files? (I presume they are.) Did you tell Perforce to treat them as binaries when you added them to source control? If you didn't, Perforce might be performing automatic line ending conversions on them which will render them useless. If Perforce has the concept of binary files, you need to mark them as such. (Be sure to do it from Windows and a local copy where they're working.)

    This is a common problem with some source control systems (e.g., CVS). I'm just not sure if it applies to Perforce as well.
     
  3. drd

    drd Bit poster

    Messages:
    3
    The workspace/project files are plain ASCII. Others are using them without issues on Windows machines, and as I mentioned, if I download the source directly to the clients virtual disk, I can use them fine. It seems I only have a problem loading them via the network Shared Folders. I think if I can trick the guest OS to thinking they're on a local physical disk I'd be ok, but it doesn't seem there is a way to do that in Parallels for the guest.

    Maybe I can reverse the process somehow? IOW, download the depot to the local disk on the guest, and share it somehow with the host (OSX)? Not ideal, but maybe an option?

    Thanks,
    ~D
     
  4. jkp

    jkp Bit poster

    Messages:
    9
    Hi there.

    I've also tried to do the same thing. I could get things to open fine, but building to a networked partition was pratically impossible - was slow as a dog. I've posted a request to Parallels to get them to add a way to have a partition on the internal drive to be mounted in the guest OS if it's not mounted in the host - that way I could have shared data partition where i store all my source-code and work from that.

    If you find a solution to this issue please post back. I'm going to try again today as my data image just got fried by a bad run of compressor :/
     
  5. tacit_one

    tacit_one Pro

    Messages:
    434
    Guys, why don't you setup your personal source control server (would it be a CVS/SVN or any other software) and use it over the network connection?
    This is just the way they were designed to be used.
    It's not a common way of development to share files between hosts - after all, they all have different line endings, etc...

    Regards.
     
  6. jkp

    jkp Bit poster

    Messages:
    9
    The point about line-endings is a good one. I'm not sure how that's going to work out...I've just managed to find a way to share disk space between the two systems so I should be able to test it out.

    Steps to share space between machines natively:

    • Create a dmg file in OS X, must be a fixed size.
    • Set the dmg file as a virtual disk in Parallels: the selection dialog doesnt permit this, but just type the path into the box and it will work.
    • Start parallels: install MediaFour's MacDrive product. Now you should have native access to the DMG.
    • Quit paralles and mount the dmg in OS X. Again, you should have native access to the space.

    I'm perturbed by the possible line-ending issue: I'd imagine Perforce changes the line-endings to be native when it pulls from the repo, probably no way around it if so.

    tacit_one: my aim is to save as much space as possible by not duplicating data - our source tree is huge, two copies of it seems a waste.
     
    Last edited: Dec 27, 2006
  7. drd

    drd Bit poster

    Messages:
    3
    It seems, after all, this is a line feed issue... at least for me... sorry, the simplest things tend to confuse me the most. All I know is I can edit the same .cpp in Visual Studio and Xcode and whatever OS specific formatting that needs to happen happens automagically via source control.

    After some digging around I found that in a Perforce workspace, you can set the line feed option to unix/mac/win/share... "share" seemed promising, of course I had to resync the whole depot (and like jkp our depot is fairly large), but whatever "share" does (insert both line feeds I assume), VS did not like either. Of course when I synced with Windows line feeds, my projects opened fine... and it seems Xcode does not choke when opening the xcode projects, so I may be able to share the source in this way, though certianly I may ultimately experience issues with binary resources, but that is far more manageable as our projects are almost entirely c/c++.

    As a side, jkp, I did try your ingenious method of mounting a dmg from Windows, and it works, though I think I found I had to unmount the image in OSX before launching Parallels/Windows or else the disk was marked read only... which I suppose makes sense ;)

    Anyway, thanks for the help guys, my goal was to save space and time by sharing the source between OSs locally, and though not a perfect solution, I think we have stumbled upon an acceptable workflow using Parallels.
     

Share This Page