I'm working on setting up version control on a company LAN using the setup described in this tutorial
The central repository is located on a Mac OS, with the developers running either Windows or Mac OS. Pushing and pulling from the central repository to a local repository on both Windows and Mac OS works.
What I can't understand is that the central repository folder appears duplicated in Windows Explorer ('CentralRepo' and 'CentralRepo-1'), yet when logged in as admin on the Mac OS hosting the central repository, this folder cannot be located. The duplicated folder can only be seen on one particular Windows computer.
Is it a temp folder? Is there anything that can be done to remove this duplicated folder?
I don't think this has anything to do with Mercurial. It's just some Windows or Samba screwiness. Because of the nature of a DVCS, you should never need to use Explorer to view the remote repo, so just ignore it.
Related
I have a MacBook Pro with OS 10.11.5 and Vmware Fusion 8.1.1 is installed.
In Fusion I have a Windows 10 (64 Bit, Ent.) running, where I have a (vmware) shared folder from the Mac OS.
This shared folder contains a Subversion Repository which is on the Mac in an encrypted Volume (a TrueCrypt-Volume mounted with VeraCrypt).
To see these handy overlay icons in Windows (if files changed etc.) I installed TortoiseSVN (64 bit, 1.9.4), but no Overlay Icons are visible in W10.
I tried the solutions in: TortoiseSVN icons overlay not showing after updating to Windows 10 but all the hints there didn't help.
I think the issue is related to Fusion's shared folder, because local repos do show overlay icons in W10.
I activated all drive checkboxes in TortoiseSVN settings but nothing changed.
I know that it is not a good idea to share a repo through different OS: SVN control of a shared virtual machine folder
but I don't want to do any commit stuff (anymore) in Windows, I just want to see the overlay icons, which are missing in Mac's OS X subversion.
And even with TortoiseSVN installed, I can commit files on the Mac without errors, if I just never touch the commit or checkout functions in W10-TortoiseSVN.
Is there anything else, I can do to see these useful overlay icons?
Thanks
frank
TortoiseSVN does not show status icons for working copies located on network shares, by default. Read the FAQ | Why are the icons only visible on local and not on network drives?.
And don't confuse Subversion working copy with a repository.
I work with git in my laptop computer (a mac) but sometimes have to use my code in a desktop machine (windows) to which I have no administrator access and which is also not connected to the internet due to security reasons.
I want to use git in that machine as well, but the IT personnel at my workplace has told me that it is not possible to install it in that particular computer room.
I have seen this thread about portable GIT (How to install Github on USB Drive?), but it seems to work only on Windows. Is there any way to make it work in both windows and mac?
I have seen threads here about how to use USB as a portable repository by starting a bare repo and cloning the contents to the other machine. I have also thought about cloning that same repo to the USB from my remote. All these solutions are not feasible because that desktop machine I want to work with has no git installed and I can't commit or do any git operation when there.
Is there any way I can have a git installation in my USB and have it working both in my laptop and in that work desktop? Can it work between two different OSs (Mac and Windows)?
Thank you for your appreciation.
Use a normal git repo on the usb drive.
Use UTF-8 as encoding for all the files to make sure that you won't get any problems with that
Before you go to your windows machine, make sure that you have checked out the branch that you want to work on.
Use the checked out files and work with them.
Back at your mac, you can commit and push and do whatever you like.
OR
Use your smartphone as usb drive. If you have Android, you can install botbrew on it and use git on your mobile. With that you can do your git operations while at your windows pc.
I am running Windows 7 64-bit Ultimate under VirtualBox (latest version, 4.1.4) on my MacBook Air. I have created a shared folder on the Mac under my user folder. I have granted read/write privileges to this folder to my account. (I also configured it with read/write access to everyone, and that did not make a difference.)
In Windows 7 under VirtualBox, I have added that folder as a shared folder.
From within my Windows 7 VM, I can see this folder, create new folders and files in it, and read folders and files, using Windows Explorer.
The problem is with Delphi XE2. If I attempt to open or save a project to this shared folder, from the Save dialog box the share (which I have currently mapped to a network drive) appears with an red X icon indicating that there is something wrong with it. If I click on this folder, Delphi displays a dialog box with the title "Restoring Network Connection" and a message "An error occurred while reconnecting E: to \VBOXSVR\Demos VirtualBox Shared Folders: The request is not supported. This connection has not been restored."
That I cannot save projects in that shared folder inhibits my ability to easily create iOS apps and generate the necessary Xcode folders using Delphi's dpr2xcode.exe utility. What I have to do instead is to create the project folder locally, run dpr2code.exe to generate the Xcode project, and then to use Windows Explorer to copy the contents of the local folder to the shared folder, where I can then load the generated project in Xcode, compile, and run it.
Does anyone know of any configuration or steps I can take to permit Delphi to see the shared folder as a valid folder?
For the record, and I have seen a similar problem with other versions of Delphi with respect to Folders from a Delphi installation in VMWare Workstation (8.0) running under a Windows 7 host. In those cases, Delphi simply does not display the shared folder.
Switch your VM to "Bridged" networking as opposed to NAT.
In VBox, select your VM, go to Settings > Network > Adapter 1 > change "Attached to" to "Bridged Adapter"
I'm guessing you've already enabled SAMBA sharing on the OSX host (System Preferences > Sharing > File Sharing (switch it on) > Options > tick "Share files and folders using SMB (Windows)")
The reason you want Bridged networking is so that your VM is assigned its own IP address, rather than sharing the IP of your OSX host (which is what NAT does).
Give it a shot, let me know if it helps :)
I would like to share a Subversion repository between my main computer running OS X Lion and a virtual machine running Windows 7 hosted in this computer (via VMware). I am unsure what is the best way to go about this.
I am thinking of setting up Apache and Subversion server on the OS X side and hopefully that would allow my virtual to access the repository from the Windows virtual using something like Tortoise SVN and accessing the repository at http://macHostName/pathToRepository. This seems feasible since the OS X side is always running.
An alternative could be setting up Apache and Subversion on the Windows virtual, which would require me to run the virtual everytime I want to access the repository from the OS X side. Perhaps Subversion can be set up in IIS? That would save some time if I don't need to install Apache.
Either way, I am unsure of the best way to go about this set up and what the caveats of each option are. I also haven't found a good walkthrough that will show how to set up a Subversion server on any OS using Apache.
Then, there is also the option of using svnserve, which I am unfamiliar with. Will a repository not served by an HTTP server like Apache be accessible for whoever is not serving it from the OS X host and the Windows virtual?
Any pointers will be appreciated.
Both Apache and svnserve are using network protocols, so the basic network setup between your host and your guest regarding routing and firewalls will be the same.
If you already have Apache installed and are familiar to it, I recommend to use it. Otherwise my recommendation is svnserve, because it is much simpler to setup and configure. The SVN-Book has a chapter for setting up svnserve both in Windows and in OSX.
Short Question
Is there a setting with git to allow a clone to use http on one OS and ssh on another? For an exact usage: Is possible to use http protocol (cloned in Windows) on Mac OS X terminal which typically uses SSH connections
Background
I have a Macbook Pro that I dual boot with Mac OS X and Windows 7. I have a shared express-34 card that I store all of my repositories / working directories on. I use this so I can work from the Mac side or Windows side seamlessly (until now). At this point, I am unable to commit / update any changes from repositories I clone / checkout from Windows. It's worth noting that git repos that I clone from Mac, work fine in Windows, just not the other way around.
System Information
Windows 7:
Tortoise git and Tortoise SVN
OS X:
homebrew installed git and SVN
Update
I am now sharing a single SSH checkout (at the project level) on both Mac OS X Lion and Windows 7. This is working when I am booted natively into Win 7 as well as when it is virtualized inside of Lion.
If I understand what you're asking I don't think this is possible using the same remote name. A particular remote is always defined by a URL which specifies the protocol. However you can add a new remote with a different URL which species a different protocol.
A problem with doing this is that you'll have the same remote with two different names in the same repository. This means that all remote branches (origin/master etc.) will be duplicated and will get out of sync which will cause problems with any git behavior that depends on branch names instead of SHA hashes.
For example, suppose you have a remote named 'windows' that specifies http and a remote name 'mac' which specifies ssh. Suppose your repository gets behind your remote you update in OSX using git fetch/merge now mac/master is up to date but windows/master is not. This may not be a big deal to you but it does mean tracking branches and other branch name dependent behavior may not work as you expect.