I'm a new mac user and recently installed mercurial on it. Id like to enable a few extensions and am looking for the global hgrc file.
I could'nt find it, so i tried creating "hgrc" files in /etc/mercurial, and ~/.hg .
It still does not work, so I was wondering if someone here had the solved the problem.
Many thanks.
Your .hgrc needs to be at ~/.hgrc, just like on other unix-like OSes (assuming you're using the standard Mercurial installation and not something like MacHg). You can use /etc/mercurial, but in that case the file is named hgrc, and not .hgrc.
You can also ask hg this question directly, and it should give you the most up-to-date answer for your installation:
$ hg help config
Configuration Files
Mercurial reads configuration data from several files, if they exist. Below we list the most specific file first.
On Unix, these files are read:
- "<repo>/.hg/hgrc"
- "$HOME/.hgrc"
- "/etc/mercurial/hgrc"
- "/etc/mercurial/hgrc.d/*.rc"
- "<install-root>/etc/mercurial/hgrc"
- "<install-root>/etc/mercurial/hgrc.d/*.rc"
I believe Mercurial looks for ~/.hgrc. Try there.
https://blogs.oracle.com/edwingo/entry/using_mercurial_on_mac_os
Related
We're using svn for version control on our Mac. Its working cool. But the only problem is we're multiple devs developing together and everyone can see any file changes status inside their Xcode ( attributes next to the file ) in their Xcode except me. How to resolve this?
This is what I want (see "M" next to the file name),
Even Xcode Source Control Menu is showing no changes.
I'm not sure if there's anything to set here?
I have checkout the code again and again, but still the problem persist.
I'm not sure, why this "Working Copies" menu "iOS" is disabled? Its enabled on other machine.
Any help would be highly appreciated.
I also encountered this problem, the following is my solution, hope I can help you.
Start the terminal, enter the code in the folder.
Type the command - svn status.
The output will be similar to this
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/Users/chao/svn/project'
is too old (format 29) to work with client version '1.9.4 (r1740329)' (expects
format 31). You need to upgrade the working copy first.
Type the command - svn upgrade.
The problem is resolved,I wish you good luck.
SVN can define status of working copy files and directories comparing your local files with the current repository located on the remote SVN server.
I believe that checking "Refresh server status automatically" will do the job.
You can say this is true when your local files will have attributes aside (U, M etc)
Having no luck, you may run the command line tool, which is usually more verbose. More details here: https://stackoverflow.com/a/19922150/195812
I have to add a project to the SVN server repository and I would be thankful to get some links or little help on how to do that.
The URL to the SVN repository is https://192.168.1.4:448/svn/BDRAsigViata/.
The project is located on the desktop. The path is /Users/name/Desktop
and the name of the project is BDRAsigurariViata v1.0.zip.
I tried to add the project this way
svn import /Users/name/Desktop/BDRAsigurariViata v1.0.zip https://192.168.1.4:448/svn/BDRAsigViata
But it isn't working. Am I supposed to follow other steps too, in order to be able to do that?
I get the error:
svn: E205000: Try 'svn help' for more info
svn: E205000: Too many arguments to import command
[Tedious mode ON] Are you trying to add a ZIP archive to a version control repository? Apache Subversion is a
version control system, not a simple file storage or Dropbox! It's designed to store and manage your code. Since you use the term "project", I assume that you simply zipped your source code files and wanted to commit them as the archive. That's not how it works. [Tedious mode OFF]
Nevertheless, the command you need is
svn import "C:\Users\name\Desktop\BCRAsigurariViata v1.0.zip" "https://192.168.1.4:448/svn/BCRAsigViata/BCRAsigurariViata v1.0.zip" -m "Commit Message"
Since you are new to Apache Subversion and VisualSVN Server you definitely should set aside some time to read SVNBook. These introductory topics are highly recommended for novice Apache Subversion users:
What Is Subversion?
Fundamental Concepts
Basic Usage
As a Windows user, I strongly recommend you to consider TortoiseSVN client (and it's manual in addition to the above docs).
Your command looks strange with the backslash. The first one and the one in front of the server URL looks like they don't belong. Also I believe you need to escape the spaces in your path. (but I wouldn't put the last file, you want a directory).
I would write this command:
svn import /Users/name/Desktop https://192.168.1.4:448/svn/BCRAsigViata
except you might not want to put your whole "Desktop folder".
I use Mercurial as source control with the main repository managed on KILN.
At one point in time I changed my iOS project name from WeatherTimeMachine to weathertimemachine.
This resulted in a case change of several files and folders:
WeatherTimeMachine.xcode
WeatherTimeMachine_Prefix.pch
WeatherTimeMachine-Info.plist
In the meantime I've added a tag to a revision in KILN... So I now have:
a head in KILN
a head on my local repo with case changes
When trying to merge I get the following error message: "Mercurial case-folding collision"
How can I fix this?
If you're on Mac OS X, you don't need to export your repository to Linux or another foreign case-sensitive file system as suggested by the Mercurial documentation. Just use Disk Utility to create a case-sensitive, journaled disk image slightly bigger than your repository, copy your repo there, then remove the conflicting files and commit.
I have found some information here: FixingCaseCollisions, but somehow this did not work for me. Here is how I managed to solve this issue:
Make a copy of your existing repository folder (for safety). For example:
cp -r WeatherTimeMachine WeatherTimeMachineCopy
Fool mercurial into thinking the problematic revision is the current tip:
hg debugsetparents <bad revision>
hg debugrebuildstate
Remove the files which are causing the problem (-f is required to force the removal). Here is an example:
hg rm -A -f WeatherTimeMachine-Info.plist
Once all problematic files have been removed, commit the changes
hg ci -m "fixed collision-folding issue" -u michael
Then restore mercurial to the proper revision
hg debugsetparents tip
hg debugrebuildstate
After this the merge is possible and the problem is gone.
And now I can happily resume working with MacHg to manage my Mercurial repository and push my change sets to KILN.
This is a no-programming no-hg answer, but it solved my mercurial case-folding problems once and for all! For now anyway..
I gave up trying to avoid and "fix" the case-collision problems. That just looks ugly and you can never really "solve" the problem, only can do a workaround.
The only way (that I can think of) to really solve the problem is to have a case-sensitive filesystem. No need to reformat your entire disk, a single partition will do the job nicely.
I used the Disk Utility app that comes with the os, pretty straightforward, just remember to select Mac OS Extended (Case-sensitive, Journaled) when creating new partition. Also, note that the Disk Utility can resize partitions only by moving the end (not the beginning) of partition.
You can probably create a symlink to where your old source code lived, so no need to change the IDE settings and stuff (but I haven't tried this, just happy with the new partition).
We resolved this without resorting to a case-sensitive filesystem by issuing HG rename commands. Say you are having trouble because "Foo.txt" needs to be called "foo.txt":
> hg rename Foo.txt Foo.txt.renamed
> hg rename Foo.txt.renamed foo.txt
We encountered this problem when a file was deleted and then later re-created in the main repository with the same name, but different case. A branch repository that was created before these changes could not then be merged in, despite the changesets from the main repository having been pulled.
For Mac OS X, what worked for me is to simply copy the folder (duplicate works - cmd-D) and continue working on it, from the new path.
OSX same I wanted to clone a repo and I had case-folding error preventing me top clone.
If the repository has multiple commit simply clone an earlier revision with this command:
hg clone -r 7
Then add anything conflicting to the .hgignore file and update.
Error message :
"svn: Can't open file '/Users/username/Projects/myproject/trunk/project/.svn/text-base/filetoupdate.h.svn-base': No such file or directory"
Question:
I have an issue I've replaced a file in a project (in Xcode) with a new file (For reference and if this makes a difference, the new file has the same name as the one I deleted previously).
Now when I try to commit my changes in Xcode I get the error message detailed above and am unable to commit the changes (i.e. adding the new file).
In the file system view (in Xcode on the left hand side of the screen) the file has an R next to it (indicating Replaced in the repository).
Does anyone know how to fix it so I can commit the files?
Thanks
There is a bug or limitation in Subversion when using case-insensitive filesystems:
https://superuser.com/questions/303348/cant-checkout-in-subversion
This bug normally shows up when checking out a repository that contains two files whose names differ only in case. Of course, these cannot exist at the same time in the same directory on a case-insensitive filesystem. SVN could give a much more helpful error message, but it can't really solve the problem.
Your issue is a bit different because I assume the file filetoupdate.h (with the old case) no longer exists in your filesystem. So it's not a case conflict in the working directory. But I guess that SVN is trying to create the file in .svn/text-base with the new case, while the old one still exists, and that is failing (for the same reason).
You could try deleting the file from Subversion first, keeping the local copy (untested). The new copy must be removed from SVN control for the commit to succeed:
svn rm --keep-local --force FileToUpdate.h
And the old copy must be removed as well, to allow us to add the new copy later:
svn rm --keep-local filetoupdate.h
Commit this change:
svn commit
Now hopefully you can add the new file to version control:
svn add FileToUpdate.h
If that doesn't work, you might need to blow away the whole checkout and start again with a fresh one.
Are you on a Mac or Windows? Those have case-insensitive filesystems which causes the above problem when
a file currently exists with the same name but with different cases.
To fix , checkout out the tree on a Linux machine, then "svn rm" one of the files.
Maybe your local version has permission issues. Check if your user have the permissions to write for the .svn directories.
good luck
It looks like something got confused somewhere. To fix, I simply copied the offending files, saved them under a new name. Removed the originals from the project and the added the copied (renamed) version of the file to the project.
It seems to be that SVN doesn't like it if you add and remove a file with the same name. I tried cleaning the SVN through terminal, but it had no affect on this issue. But changing the name did work for me.
Git-svn allowed for a duplicate filename, just with different case, to be added to our subversion repository.
On Windows this meant that subversion could not checkout the file, complaining of a duplicate.
Another developer deleted the incorrectly cased version from the repository. Now when trying to do a git-svn rebase I get a "could not detach HEAD" message and a complaint about the file name in question being untracked and needing to be overwritten. Deleting the file makes git-svn complain that the file needs to be updated.
Is the only solution to copy the repository to a machine with a case sensitive filesystem do the rebase then move it back?
I understand that git-svn isn't ready for real world work on Windows but I'd like to recover from this mess it has created.
Best current answer (I don't know if this existed back when this was originally posed):
git config core.ignorecase true
Then redo the rebase. It will proceed without error -- and will even properly handle the case change in the filename.
This isn't specific to git-svn. It can happen in a straight 'git rebase'.
I hope that helps the next person....
I ran into a similar problem with Git (alone, not even with git-svn) getting very confused about changing the case of filenames when using a case-insensitive Mac filesystem. I didn't find a solution to fix the repository on the case-insensitive filesystem, but instead created a new case-sensitive volume in a .dmg file, mounted that, and used Git on that volume instead.
You may find that some of the Git "plumbing" commands might be helpful. For example, git checkout-index has a -f flag to force overwriting of existing files (also use -a with that command otherwise it might not do anything). The plumbing commands are generally more powerful (and more dangerous) than the porcelain commands, but may give you the flexibility you need to fix this.
The same way you always solve this problem under Windows. You have to rename one of the files, then you can restore the other one.