I am using XCode 4.5 and I use the build in Source control, I have modify a file and still not committed, I tried to access this file form another iMac and modify the same file and there is no problem with modifications.
The issue is how I can own this file and no other developer can modify it until I commit it?
Using git? You don't. That's not how git works, there's no concept of "file locks" and they wouldn't make sense in a distributed version control system. You'll have to actually talk to the other developers if you think it is important to avoid merge conflicts on that file.
Related
I have this problem with ankhsvn:
i have the solution up to date , but not its unique project . When i try to commit i got this error
when i click into Show changes i have some changes in a temporary file integration_finale.csproj
So, What are the reasons of this error? How can i fix it?
The csproj file is not a temp file. It governs your project set-up and settings for references, paths, build details etc.
From how it appears this conflict can (probably) use local as it appears the rest of the file is correct (at least from the image). It appears that the change is just that the SpecificVersion flag for he reference has been changed to the default setting.
Now you should backup this file and confirm the rest of the file is correct. If you corrupt this file you will have to rebuild the project file (csproj).
'Clean' solution via AnkhSVN and get update again
if above does not works then I would suggest you to take backup of your current .csproj file. Then update the file to latest commit version on svn. After which you can merge code and commit your changes.
better use TortoiseSVN
I use ankhsvn, and I know that it has a few bugs. To diagnose (and better handle conflicts too) this kind of problems I use also TortoiseSVN.
My team is using GitHub with Xcode. We use the GitHub application for OS X to commit, branch and sync. The problem is that when two or more developers add files to the project, conflicts occur in the 'project.pbxproj' file. Recently I realized there is a commit/push/pull option in Xcode.
If I stop using the GitHub application and use Xcode's commit, push, pull and merge, would those conflicts in 'project.pbxproj' file stop occurring?
You can still have conflicts.
If somebody makes a change to the project file and you make a change to the project file and you try to commit it at the same time as (or soon after) the other person, there's a good chance you'll see conflicts.
Thankfully, the "project.pbxproj" project file is text which can you can open with your favorite editor (vi or emacs or whatever) and you can resolve the conflicts rather easily.
Is there are means whereby if files are altered outside of Xcode, that a warning in can be shown to ask if you want to refresh the file? This feature is available in Visual Studio, for example.
As a temporary solution, were working on source files in a Dropbox folder.
Although growl notifies us that some files has changed, Xcode doesn't know about these changes.
No, Xcode won't do that, and since there's no support for plugins you're pretty much stuck with that behavior. Some suggestions:
Create a local git repository (Xcode can do this for you when you create the project, I don't know if you can do it once it is created.
Use another IDE, like AppCode (this isn't even a solution, just came to me and I decided to add it).
With a version control system you can see the little 'M' on edited files, browse changes, etc. But since you wrote that this is a temporary solution I bet you already know this.
I have been using XCode with subversion for some time now, no problem was caused when I was using it as a single developer (I was using 2 commands only, commit and add).
But now I have to share the code with another developer (who has never used any kind of version control) and integrating/merging the code has become a nightmare. No problem occur when we are integrating/merging .h/.m files but as soon as it comes to ".nib", "xcodeproj" and ".xcdatamodeld" files, we really don't know what to do.
Whenever we try to merge "xcodeproj", project was getting corrupt and merging ".xcdatamodeld" was kind of impossible for us.
So I was wondering if someone can share his/her experience on how to effectively use subversion/git/mercurial with XCode 4.0 in multiuser environment? or share a link, which can explain how to use subversion effectively in multiuser environment.
Thanks.
Are you doing this using Subversion? For 90% to 99% of the files in your repository, the standard Subversion workflow of checkout, edit, commit works well. However, for some types of files such as JPEGS and GIFS simply don't merge well. In this case, you'll have to do it the way we use to in the old SCCS and RCS days: Before you can edit and commit a file, you must lock it.
Locking a file prevents others from editing the same file and committing changes while you're doing your work on the file. It's crude, but it works. In Subversion, you can always lock any file you're editing, but if the file has the property svn:needs-lock on it, it will be checked out as read-only. You have to lock the file before editing it to make it writable, and you're not allowed to commit the file unless it is locked.
So, for those files, set the svn:needs-lock property on it.
You can automatically set this property on all newly added files (depending upon suffix) via setting the auto-properties in your Subversion client configuration.
And, if you really, really want to make sure that all .nibs and xcodeproj and all of the other flies of these types have svn:needs-lock set on them, you can use my pre-commit hook which will prevent these files from being committed unless this property is set.
There is no failsafe way to merge these kinds of files that I am aware of. So you will have to
try to ensure that only one person is changing these files at a time. That won't work always, so just log what you changed in the file with the commit message. Then if there is a conflict, you can manually resolve it by taking the version that changed more of the file and redo manually what the other person did.
That's normally not a big deal, like adding a new source file to an .xcodeproject, or changing the alignment of an element in a .nib. It's becoming a problem if your project is huge or your nib is containing the whole interface. For it to work well (which in practice it does), you need to split up your projects into sub-projects if they grow too huge.
I had the same problem with 2 other developers Xcode with git. Unfortunately, Xcode project files are an XML file, tracks file included in the project as well as setting. I'm not certain, but I think .nib files are also XML files as well. Someone can correct me on that.
Git did a great job at merging the Xcode project file, and never really had any problems with our *.nib files either. The only time we did have a problem is when we both added/removed files with the same names, or someone did a lot of heavy removing and adding of a lot of files.
The only way we solved this was to have each other push ann pull as soon as we added/removed files. So that way the person had the latest files, and didn't add them in their own repository then pull the latest commit which had the same file in it. Or they work adding changes to a file that was removed or renamed.
That is the best solution we found, as soon as we added or removed a file have everyone else in the team pull. Not a great solution btw. However, you should be committing often anyways.
So you know a lot of Mac apps use "bundles": It looks like a single file to your application, but it's actually a folder with many files inside.
For a version control system to handle this, it needs to:
check out all the files in a directory, so the app can modify them as necessary
at checkin,
commit files which have been modified
add new files which the application has created
mark as deleted files which are no longer there (since the app deleted them)
manage this as one atomic change
Any ideas on the best way to handle this with existing version control systems? Are any of the versioning systems more adept in this area?
Mercurial in particular versions based on file, not directory structure. Therefore, your working tree, which is a fully-fledged repository, doesn't spit out .svn folders at each level.
It also means that a directory that is replaced, like an Application or other Bundle, will still find it's contents with particular file names under revision control. File names are monitored, not inodes or anything fancy like that!
Obviously, if a new file is added to the Bundle, you'll need to explicitly add this to your repository. Similarly, removing a file from a Bundle should be done with an 'hg rm'.
There aren't any decent Mercurial GUIs for OS X yet, but if all you do is add/commit/merge, it isn't that hard to use a command line.
For distributed SCM systems like git and mercurial shouldn't be a problem as Matthew mentioned.
If you need to use a centralized SCM like Subversion or CVS, then you can zip up (archive) your bundles before checking them into source control. This can be painful and takes an extra step. There is a good blog post about this at Tapestry Central:
Mac OS X bundles vs. Subversion
This article demonstrates a ruby script that manages the archiving for you.
An update from the future:
If I recall, the problem with managing bundles in SVN was all the .svn folders getting cleared each time you made a bundle. This shouldn't be a problem any more, now that SVN stores everything in a single .svn folder at the root.
Bringing this thread back to daylight, since the October 2013 iWork (Pages 5.0 etc.) no longer allows storing in 'flat file' (zipped), but only as bundles.
The problem is not the creation of version control hidden folders inside such structures (well, for svn it is), but as Mark says in the question: getting automatic, atomic update of files added or removed (by the application, in this case iWork) so I wouldn't need to do that manually.
Clearly, iWork and Apple are only bothered by iCloud usability. Yet I have a genuine case for storing .pages, .numbers and .keynote in a Mercurial repo. After the update, it blows everything apart. What to do?
Addendum:
Found 'hg addremove' that does the trick for me.
$ hg help addremove
hg addremove [OPTION]... [FILE]...
add all new files, delete all missing files