I'm moving from StarTeam to SVN, and I've decided to take snapshots of each of our releases. However, I'm experiencing a problem when dealing with files which existed in revision 1 were deleted for revision 2.
How do I commit the snapshots when files are missing?
I've tried fully deleting the trunk/src/ folder and then replacing it with the new /trunk/src/ folder, but that seems to cause conflicts with missing files. When I
svn add" everything, TortoiseSVN seems to detect that the files were missing, and when I commit it seems to attempt to delete the missing files, but it seems to fail. Presumably this is because it's trying to delete directories after deleting the files in that directory?
I'm getting the following error:
deleting C:\trunk\src\myfile.h // this one's okay
deleting C:\trunk\src\res
Commit failed (details follow):
Directory 'C:\trunk\src\res' is out of date
Item '/trunk/src/res' is out of date
You have to update your working copy first.
What is a solution to this problem? Surely I'm not the first to run into this issue, but I cannot seem to find anything on google or stackoverflow. Some people suggest running a script to do it, but I'm still confused about the process. Do I need to delete my old trunk folder so that the missing files will get removed locally? Or should I diff and delete with a script?
Thanks!
Old (unclear) post: Migration to SVN, confused about deleting old files
Edit:
This is going from one snapshot to the next. I'm migrating from a different repository (StarTeam), so I didn't have anything in trunk. I just want to check in all the different snapshots and have the files which were deleted be removed as well. Isn't it a bad idea to tag if I don't have anything in trunk?
There's actually a Subversion script that does this for you called svn-merge-repos.pl
I'm not 100% sure you're understanding the concept of how Subversion works. Did you go through the Subversion book?
In Subversion, there are no real tags/labels or branches metadata like you find in many version control systems. Instead, you put tags and branches in their own directories. To create a branch or tag, you copy what you want to branch or tag into the directory:
# Creating a branch for 2.0 development from trunk
$ cp http://server/svn/module/trunk http://server/svn/module/branches/2.0
# Tagging my 2.0 development as 2.0.1
$ cp http://server/svn/module/branches/2.0 http://server/svn/module/tags/2.0.1
In theory, you can simply create a new branch or tag directory for each release and branch you're working on without a need for merging repositories. That's what I did when I did a StarTeam to Subversion conversion. The problem is that you lose the relationship between say revision 2.0.1 and 2.0.2 since they don't share a common history. 99% of the time, that's not really a problem, and you can always go back to the original StarTeam archive if you need anything. In a few months, no one will care.
However, if you know the relationship between branches and tags, and want to keep that information, you'll have to do the two step script I described above.
For example, you have a 2.0 branch that comes from trunk, a 2.0.1 tag, a 2.0.2 tag, and a 2.0.3 tag, you might want to do this:
Put branch 2.0.1 release onto trunk.
Copy trunk to branches/2.0.
Put the next branch on trunk and copy it to its branch (use the svn-merge-repos.pl script)
Finally, put the current trunk.
Now go to that branches/2.0 directory and copy that to tags/2.0.1. Using the svn-merge-repos.pl script, create the 2.0.1 release on branches/2.0 and copy that to tags/2.0.2. Keep going until you get to the tip of the 2.0 branch.
That takes a lot longer to do, but it's feasible. Last time I did that, it took me about a week and a half to do the entire conversion. Fortunately, I did the trunk first and then the active release which I could do in a day. Then, worked my way back to the less active stuff.
I'm certainly not an expert on SVN, but I believe that you've got to issue the svn delete command for the items you want to delete upon the next commit. It's described here.
You should create a tag instead.
EDIT:
svn status list all changes
you can print all deleted files like this:
svn status | grep -E '^!' | awk '{print $2}' > /tmp/changes
You can do a svn delete on each file with a batch ;)
EDIT: (SVN Migration How-To)
Let's assume you have a project named projectA, and a blank SVN repository.
First, you should create a Folder structure like this:
projectA/
|-- branches
|-- tags
|-- trunk
Then import your project files.
projectA/
|-- branches
|-- tags
`-- trunk
|-- README
`-- src
After the import you can create a tag to "mark" the initial release:
projectA/
|-- branches
|-- tags
| `-- release-1
`-- trunk
|-- README
`-- src
After this point, you should edit your files as you like.
When you think all your edits are "Good", then commit.
After some commits, if you want to release, create a tag.
Trunk should always contain the up-to-date version of your code.
I highly recommend you to use TortoiseSVN on Windows if you are a rookie ;)
You should use svn-load-dirs.pl:
"This Perl script is designed to load a number of directories into
Subversion. This is useful if you have a number of .zip's or
tar.{Z,gz,bz2}'s for a particular package and want to load them into
Subversion."
Basically what you do is:
export all you tags chronologically
create an empty repository
use svn_load_dirs.pl to "stack" tag after tag in your subversion.
svn_load_dirs.pl creates a single revision for each tag and you can as well create a (subversion-)tag after each import. It will keep track on all deleted and added files and will perform the appropriate svn actions. This means you can explicitly start with an empty trunk
From your question, it looks like that you are completing misusing SVN. There is no point in deleting the entire trunk/src folder and replacing it with a new one except in case of a huge change in the code.
Instead, create a tag for the release.
Related
Yepp, I'm quite new to Fossil…
During my experiments I've faced a problem: fossil all info command lists all and every repos ever touched here including those removed/deleted/dropped/erased/got-rid-of quite obviously failing like that
************* /home/jno/src/dropped-repo.fossil *****************************************
SQLITE_CANTOPEN: cannot open file at line 36667 of [0c55d17973]
SQLITE_CANTOPEN: os_unix.c:36667: (21) open(/home/jno/src/dropped-repo.fossil) -
fossil: [/home/jno/src/dropped-repo.fossil]: unable to open database file
Yes, the --dontstop flag makes the life a bit easier, but does not fix the things.
So, the question is: how to properly remove a repository?
The only way I found so far is:
fossil close it
remove the repo file itself
run sqlite3 ~/.fossil and delete from global_config where name='…' on all mentions of that repo.
This looks ugly.
I see a new/init command to create a repo, but I see no way to remove it.
PS. The recipie from Fossil: "not a valid repository" - deleted repository (just rm ~/.fossil) looks an overkill.
For the fossil all command to ignore a certain (past or present) repository, you should use fossil all ignore.
In short:
fossil close closes a working directory (by deleting the .fslckout file)
rm /home/jno/src/dropped-repo.fossil actually deletes the repository (only do this if you really want to throw away the entire repository, including all versions)
fossil all ignore /home/jno/src/dropped-repo.fossil removes the repository from the list of repositories that's used by the fossil all command.
I'm learning how to use django on a EC2 server, but i am editing the code on my local computer. When i run things like :
python manage.py startapp polls
It creates a folder with various files inside. Instead of individually adding the files to git, which leaves the possibility of me forgetting to add every newly created file, is it good practice just to:
git add (the root django project directory)
everytime django creates new files?
If this isn't good practice, what methods do you guys use to ensure that all files get added to git everytime new files are created?
I think you're over-thinking this. Ignore files you think you should (like *.pyc). Add all the files or do them individually, whichever you prefer. If you accidentally added one you shouldn't have, do a checkout of that file so that you don't add it. If you already committed with a file, git delete the file and commit.
You use git status, it will give you the list of all the files it's currently not tracking, so you can use that as a reference if you're afraid you'll forget something.
Additionally, I would say that you don't want to forget to properly setup your .gitignore, and then you can instruct git to add everything, otherwise, like Mark suggested, you would potentially be adding **.pyc* files, which you don't want to do.
I have a StarTeam repo that I'm trying to migrate to SVN. Unfortunately the repo is HUGE, so I can't use any of the polarion scripts, etc. I'm resorting to checking out snapshots of each release in StarTeam and then manually adding/committing them to SVN.
However, I'm confused about what to do for old files. In StarTeam, we had to move deleted files to an "obsolete" folder since the purge command removed all copies of the file. I know that I don't need to do that in SVN, but how does SVN deal with files which have been deleted/are missing?
Say I have three files in the following structure:
trunk/
Src/
A.cpp
B.cpp
C.cpp
If from one release to another I deleted "C.cpp", do I just need to commit all of src for the deletion to be reflected in the SVN repo?
Likewise, if I deleteed "C.cpp" but added "D.cpp", I would need to call add on all of "src/" before committing. Would that cause any problems with detecting and deleting the missing files? There are too many of them to go through manually and delete every one individually.
As a separate question, is there a reason why it takes tortoiseSVN almost 3 hours to detect which files are changed before I can add/commit? All I see is the "Please wait..." message in the dialog box, and it takes FOREVER.
Thanks!
Any change you make to the repo needs a commit, so yes after doing svn delete you need to svn commit. Similarly when you add files, that's a change that needs to be committed. In both cases it's possible to undo the add and delete without commiting.
In terms of adding and removing files in one transaction, again that "just works", you'd effectively issue:
svn delete C.cpp
svn add D.cpp
svn commit
If you want to recover a deleted file, then you can just recover the file from an earlier revision of the svn repo, then recommit (see also What is the correct way to restore a deleted file from SVN?).
The main thing you must remember though when deleting files: you must delete it using subversion tools (i.e. from the command line as svn delete or using Delete within TortoiseSVN. Just deleting it using del, rm, or a file manager like windows explorer will have SVN see the file as "missing" and not "deleted", and a commit of the repo will not commit the delete; thus the next time you update your working copy, the missing files will be restored. Thus you use subversion to delete the file so subversion knows that you do actually want it deleted.
For your last question -- what version of SVN and how big is the repo (in terms of file-count). Essentially T-SVN has to walk the tree and check each file against the repo-version to see it it's changed. As of SVN 1.7, the working copy format changed with a lot of metadata being held in the database, and improvements to the storage of pristine copies (i.e., what the file looked like when it came out of svn) means that it's faster than it was. If you aren't using 1.7, then it's worth checking out. Also, if you have a large repo but only work in a small part of it then consider using sparse checkouts to reduce the size of your local working copy. See this answer to Checkout one file from Subversion for a brief overview or sparse checkouts.
I have a django project that I have been working on as a solo developer, and have been using TortoiseSVN to keep the code managed in a repository on a work server. I work on this on a local installation of django etc.
There is now a second person who will be working on this project, and the possibility of working on some other PCs.
Now, there should, for the time being, only be one development version (branch?) of this project, but the configuration file (settings.py) will need to be different on each computer that is being used. I want to create one local version of this file on each PC which should not need to be changed again.
How can I set the repository (preferably within TortoiseSVN) to exclude this one file? E.g. the repository should not include settings.py. When a checkout occurs, it should update all files in the local folder but not change/remove the local copy of settings.py. When a commit occurs, settings.py should be ignored and not uploaded.
At the moment settings.py is overwritten/updated as per any other file in the project folder/repository.
Any nudges in the right direction would be useful - I'm new to SVN generally and would like to know if this is something that's going to need detailed understanding of branching or if there is a simpler way.
Thanks
In TortoiseSVN, when you try to commit your files, in the file list dialog, right click the file and look for the Ignore option. You can ignore by complete filename or extension.
If the file is already in the repository, and you want to remove it from there and ignore it, you can simply right-click the file and in the TortoiseSVN menu look for the 'Delete and add to ignore list' option.
You'll be looking for the svn:ignore property, which tells subversion to not version files matching a pattern or patterns you specify.
There's some guidance on using it with TortoiseSVN at:
http://arcware.net/tortoisesvn-global-ignore-pattern-vs-svn-ignore/
These should help:
I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
Excluding Items from the Commit List
The typical solution is to do what bgever said and ignore the settings file itself, and then commit a file with example values, something like settings.py.example. That file should only be updated when you add or remove settings. When deploying, you'd copy that to settings.py and edit the values.
I use git to interface with an SVN repository. I have several git branches for the different projects I work on.
Now, whenever I switch from one branch to another using 'git checkout ', all the compiled executables and object files from the previous branch are still there. What I would like to see is that switching from branch A to B results in a tree with all object files and binaries from the last time I worked on branch B.
Is there a way to handle this without creating multiple git repositories?
Update: I understand that executables and binaries should not end up in the repository. I'm a bit disappointed in the fact that all the branching stuff in git is useless to me, as it turns out I'll have to clone my proxy git repository for every branch I want to start. Something I already did for SVN and hoped to avoid with git. Of course, I don't have to do it, but it would result in me doing a new make most of the time after switching between branches (not fun).
What you want is a full context, not just the branch... which is generally out of scope for a version control tool. The best way to do that is to use multiple repositories.
Don't worry about the inefficiency of that though... Make your second repository a clone of the first. Git will automatically use links to avoid having multiple copies on disk.
Here's a hack to give you want you want
Since you have separate obj directories, you could modify your Makefiles to make the base location dynamic using something like this:
OBJBASE = `git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1\//'`
OBJDIR = "$(OBJBASE).obj"
# branch master: OBJBASE == "master/", OBJDIR == "master/.obj"
# non-git checkout: OBJBASE == "", OBJDIR == ".obj"
That will but your branch name into OBJBASE, which you can use to build your actual objdir location from. I'll leave it to you to modify it to fit your environment and make it friendly to non-git users of your Makefiles.
This is not git or svn specific - you should have your compiler and other tools direct the output of intermediate files like .o files to directories that are not under version control.
To keep multiple checkouts of the same repo, you can use git --work-tree.
For example,
mkdir $BRANCH.d
GIT_INDEX_FILE=$BRANCH.index git --work-tree $BRANCH.d checkout $BRANCH
You could set your IDE compiler to generate all private temporary files (.class and so on) in <output>\branchName\....
By configuration your compilation setting branch by branch, you can register the name of the branch in the output directory path.
That way, even if though private files remain when you git checkout, your project on the new branch is ready to go.
In the contrib/ directory of the git distribution, there is a script called git-new-workdir that allows you to checkout multiples branches in different directories without cloning your repository.
Those files aren't tracked by Git or Subversion, so they're left alone on the assumption that they are of some use to you.
I just do my checkouts in different directories. Saves me the trouble of doing cleanup.
A make clean should not be necessary because files that are different between different branches get checked out with the actual date!!!
This means that if your Makefile is correct, only those object-files, libs and executables are compiled again that really changed because of the checkout. Which is exactly the reason a makefile is there in the first place.
The exception is if you need to switch compiler options or even compilers in different branches. In that case probably git-new-workdir is the best solution.
If the compiled executables are files that have been checked in
then git stash solves the problem.
[compile]
git stash save "first branch"
git checkout other_branch
[Fiddle with your code]
[compile]
git stash save "second branch"
git checkout first_branch
git stash apply [whatever index your "first branch" stash has]
# alternatively git stash pop [whatever index...]
If the compiled executables are files that have not and will not be checked in
then simply add them to .gitignore