I basically want to do an SVN export as part of a scripted build process, but without having to get the entire repo from scratch every time, which is slow and eats bandwidth... not to mention will make testing the script a pain in the backside if it does this everytime we tweak something or spot a typo in the scripts.
Is there an obvious way to do an export into an existing directory, so only files that are different are fetched, and non-repo files are deleted, basically giving a clean export but done in a smart way?
Windows is preferred, but I guess Cygwin is an option.
I think the only way to get this done, is to checkout a working copy, and update & revert that. Updating a WC only gets the changes.
svn export doesn't know what files are changed, and to compare files, you first have to fetch all of them. Also it would be hard to get files that were deleted or renamed out of your 'export' directory.
Checkout a working copy, then export from your working copy.
SVN update on the working copy will then be quick and bandwitch light.
Then you can delete the original export and re-export from the working copy.
All the bandwidth hungry operations are optimized. The heavy handed delete and re-create is the same as it was before, but it's now all local, so should be much faster.
Also, you have the option to make changes in the exported working copy, but you might want to be careful with that and consider the impact of having conflicts occur during your svn update.
I am not sure if I understand your question right. To rephrase it. I think you would want to have the repo local copy updated on a regular basis. However you would want the working copy pristine so that the resulting build is a clean. Considering this is your question below is what I would suggest.
To my knowledge svn export might not be the be best option for this. Because the purpose of svn export is to obtain a unversioned working copy of the svn repo. As it is unversioned, svn client would not really know from where it has to start the update.
The best option i can think of is this. Checkout the copy of the repo (local copy, LC) in a location. This LC should be updated during the build process. Make a copy of the LC in a different location and use it for performing the build. Below are the commands you would require
1. svn update <arbitrary path>(in the working copy)
2. copy <arbitrary path> <build path>
3. find <build path> -type 'd' -name '.svn' (if you would like to remove the .svn hidden files, but they are not going to really hurt the build process)
Some Options for Eliminating the copy time from factoring in the build process time
If you would like to save the copy time during the build process probably you can do this copy operation after each build and svn update the copy just before building (assume the .svn folders are retained).
On linux two folders can be kept in sync using rsync. The build copy can be made to reflect the updates in the pristine copy.
In Windows, there are a few tools to achieve sync suggested above. I have not used them but I will provide you the links to try it yourself.
http://lifehacker.com/326199/synchronize-folders-with-synctoy-20
http://www.techsupportalert.com/best-free-folder-synchronization-utility.htm
Another option is to use checkout and revert / update but also use something like the SharpSvn library to make a script that will delete non-source controlled files. This way build artifacts like compiled code will be removed and the versioned files will be returned to base state by the revert / update.
If you have a lot of directories and files this scanning could be slow, but if you are confident about what directories will contain build artifacts would can just scan those.
Related
I'm new to git and have a git repository that I use with GitKraken.
In this repository I have multiple branches, and can move from branch to branch in order make modifications where necessary.
I am now in a situation where I'll be making some large modifications to 1 branch that I do not want to commit but in the meantime I would like to make some minor modifications to another branch.
I'm used to work with TFS and there I can just checkout branch to another folder.
I've tried to just copy the folder and my first impression is that this should work....
But, I have seen online remarks that say that I should clone a repository instead.
The git version is lower then 2.5 so I can't use Git-worktree.
Is it ok to just copy the folder or can this have an unexpected effect?
Yes, if you copy the whole folder from the root of the checkout, including the hidden .git folder, then you can make changes to each working copy independently. Each contains their own copy of the repository objects and they will behave exactly as if you have run two separate clones.
As discussed in the comments this isn't necessarily a good use case for this, though: it would be easier (and more disk-space-efficient) to commit your large changes to a local branch so that you can then switch and make other changes. There's no real downside to this; if you do want to remove that temporary commit later then that's easily done as well.
However if you are going to do this, then you probably want to
run a git repack -ad first, so that there are fewer files in the objects tree to copy
consider using git clone --reference instead, which might be slightly more disk-space-efficient
or you want a clean working copy you can create a new working copy folder, copy only the hidden .git folder into the new working copy and then git reset --hard to check out all of the files there too.
You may want to see if git stashing will work for you. I don't recommend copying to a new folder. Mostly because I don't know if it's even possible and I've never seen that as a recommendation. Cloning should also work but it sounds like you are interested in shelving/stashing vs. committing your changes in branch1 before checking out branch2.
https://git-scm.com/book/en/v1/Git-Tools-Stashing
I am working on a Swift based XCode project that is synced with Git based master repository. One of my team member has added few files, to the master which I have pulled.
I find those files in my project directory, but not in my project. When I am manually trying to add these files to the project, in that case, I am getting Modify tag on my project, then I am unable to pull new changes from master.
This is very annoying. How do I take care of this.
Also, how do we make sure as a team that everyone of us is working separately on different module, and make surely everyone is able to commit/pull each other's changes.
The project folder with M tag is prohibiting us from doing so.
Edit 1
I have followed steps for this as well
git rm -r --cached ProjectName.xcodeproj
git commit -m "Removed file that shouldn't be tracked"
Even after doing this,
I had made changes in File1.swift, with my team member's changes in File2.swift
He had already committed it, I wanted to pull those changes, however due to changes in File1.swift I was unable to pull it.In order to make it work, I had to discard changes in File1.swift and then only I was able to pull those changes. If this is so, then it is defeating the purpose of using git
Xcode project files
The Xcode project file, or to be more precise, the pbxproj file inside the xcodeproj container keeps track of all files (among other things). Unlike Eclipse, Xcode does not monitor your source/project folder for changes thus does not update the list of files which can lead to inconsistencies after a merge.
Merge conflicts
If your team member adds or removes a file in his local copy of the repository and pushes his changes to the server, he basically overwrittes the pbxproj and therefore updates the list of files of the Xcode project. If you pull those changes there are two possible scenarios:
Git can merge the changes automatically which usually means it will keep your copy of the pbxproj file without the updated file references.
Git cannot merge the changes and therefore indicates a merge conflict that you need to resolve yourself. Depending on the differences and amount of changes these merge conflicts can be pretty annoying to resolve. Sometimes it might be easier to just delete your copy of the pbxproj file, use the one from the server and reapply your local changes, e.g., add file references.
In both cases you might need to compare your pbxproj file against the one from the server and merge things by hand. And yes, your project file will be marked with an M (for modified) which is perfectly fine. Just commit your changes and you are good to go again.
One more thing: Whenever you want to pull changes from the git server you can either stash your changes (git stash) or commit them.
Avoiding merge conflicts
In case you want to avoid merge conflicts in the future, I recommend having a look at the following tools.
Cocoapods
Cocoapods can be used to modularise your project into smaller pieces by creating private Pods. The benefit of this technique: You do not have to keep track of newly added or removed files. Just run pod update and you are up and running again. There are several blog posts that describe this technique in detail, e.g., here
phoenx
At my former company we had a pretty huge codebase and ran into some trouble when using Cocoapods. Therefore, we have developed our own meta-build system called phoenx. Phoenx can generate Xcode project and workspace setups of arbitrary complexity. It uses metadata files (something like Podfiles and Podspecs) to generate the projects etc. . Build settings will be stored in xcconfig files. At the moment it does not provide any setup tool so you have to invest a bit of time to write the xcconfig and metadata files by hand. We are working on a more convenient way to use it though. If you want to give it a try you can install it via sudo gem install phoenx. Documentation is available on GitHub.
Hope that helps!
We have an existing repository on the network accessed via HTTP:.
Should I first import these files to my local machine? I tried importing directories, files, etc., everything is empty in my local folders. It says "success", but nothing ever shows up!
It doesn't make sense to create a repository on my side. But all the tutorials seem to say that, but then I think they're assuming you're starting from nothing.
My experience with Tortoise SVN has mostly been negative. Typically whatever I think I should do turns out to be incorrect, and I end up having to undo, and redo, or lose my work. Once I even managed to corrupt the main repository and it had to be restored from backup.
I absolutely cannot damage this existing repository!
If you're used to CVS or some older version control systems, note that SVN uses the same terms differently. In those, checkout often means lock in exclusive mode.
In SVN checkout will make a copy and automatically manage the revisions and help you merge from multiple sources. You don't need to lock a file, unless it's graphical or some other binary where merging doesn't make sense.
So in TortoiseSVN, you can checkout, and edit the files. The icons on the files will change to indicate their status.
SVN is easy in comparison to git, where the same terms are again redefined and significantly augmented!
I have a working copy of a SVN repository. C:\myrepo on my computer points to https://example.com/svn. It has a subfolder in it, /foo/bar. This folder is really big and it's a remote repository, so checking it out again would take a very long time. I'd like to give my colleague a working copy of just /foo/bar, not the whole repository (because the whole repository is even bigger and contains a bunch of stuff that will confuse them).
I can make a copy of my working copy, C:\myrepo-bar and then use svn switch https://example.com/svn/foo/bar but it says there's no common ancestry (which is true) and so (if I force it) it checks out the whole folder again.
Is there any way to get around this and get a working copy of just https://example.com/svn/foo/bar given that I have a working copy of https://example.com/svn already? I'm using tortoiseSVN but I'm comfortable enough using SVN on the command line.
That depends. In general: no. SVN working copies are not like Git or Mercurial repositories; they do not contain any history or other information that is contained in the repository, only a copy of the selected version of the files.
If, however, you are using an old version of the SVN client, a version old enough to put a ".svn" directory in every subdirectory of your project, then you may be able to just copy the subdirectory (including the .svn directory inside). I'm not sure if this will have consequences with username or whatever, I only ever did that for my own use. And, recent versions of the client have removed the .svn directory from all but the working-copy root, so this is not an option for recent clients.
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