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.
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.
As I understand the directories of each file fossil.exe, repository-file and files (to be versioned) can be in totally different pathes, is that right?
However, I get the following error:
file outside of checkout tree: path_to_file\filename
My structure is as follows:
FOSSIL\fossil.exe
NewFolder\repo.fossil
NewFolder\Subfolder\sample_table.csv
When opening the repo and then running fossil add full_path\sample_table.csv I get the above mentioned error.
A few things:
It doesn't matter where the fossil executable is located, as long as it's somewhere in the search path (otherwise you have to use the full path every time).
It doesn't really matter where the repository file is located either, as long as it doesn't move after you've opened it. (If you do want to move it, close the repository first).
You're missing a work directory. You need to open the repository first, into a work directory (also called the checkout tree). That work directory will be where you'll be working on your files.
In the situation you describe, you'd need to run the following command:
cd <topmost folder of your code>
fossil open NewFolder\repo.fossil
After that, you can do whatever you need in that folder (and its subfolders), and anytime you perform a commit or checkin, the changes you've made will end up in the repository.
fossil add NewFolder\Subfolder\sample_table.csv
fossil commit --comment "Added sample table"
There's usually no reason to close the working directory again; except perhaps if you want to move the repository: you'd then use fossil close to close the working directory, move the repository, and then use fossil open <new_repo_path> from the working directory again.
Note that the repository can be located somewhere else entirely; and also that a single repository can be opened into several different work directories at the same time.
How I can build local sources and dependancies with flatpak-builder?
I can build local sources
flatpak build ../dictionary ./configure --prefix=/app
I can extract and build application with dependancies with a .json
flatpak-builder --repo=repo dictionary2 org.gnome.Dictionary.json
But no way to build dependancies and local sources? I don't find sources type
like dir or other, only archive, git (no hg?) ...
flatpak-builder is meant to automate the whole build process, with a single entry-point: the JSON manifest.
Everything else it obtains from Git, Bazaar or tarballs. Note that for these the "url" property may be a local URL starting with file://.
(There is indeed no support for Hg. If that's important for you, feel free to request it.)
In addition to that, there are a few more source types (see the flatpak-manifest(5) manpage), which can be used to modify the extracted sources:
file which point to a local file to copy somewhere in the extracted sources;
patch which point to a local patch file to apply to the extracted sources;
script which creates a script in the extracted sources, from an array of commands;
shell which modifies the extracted sources by running an array of commands;
Adding a dir source type might be useful.
However (and I only flatpaked a few apps, and contributed 2 or 3 patches to the code, so I might be completely wrong) care must be taken as this would easily make builds completely unreproducible, which is one thing flatpak-builder tries very hard to enable.
For example, when using a local file source, flatpak-builder will base64-econde the content of that file and use it as a data:text/plain;charset=utf8;base64,<content> URL for the file which it stores in the manifest included inside the final build.
Something similar might be needed for a dir source (tar the folder then base64-encode the content of the tar?), otherwise it would be impossible to reproduce the build. I've just been told (after submitting this answer) that this changed in Git master, in favour of a new flatpak-builder --bundle-sources option. This would probably make it easier to support reproducible builds with a dir source type.
In any case, feel free to start the conversation around a new dir source type in the upstream bug tracker. :)
There's a expermental cli tool if you want to use it https://gitlab.com/csoriano/flatpak-dev-cli
You can read the docs
http://docs.flatpak.org/en/latest/building-simple-apps.html
http://docs.flatpak.org/en/latest/flatpak-builder.html
In a nutshell this is what you need to use flatpak as develop workbench
https://github.com/albfan/gnome-builder/wiki/flatpak
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'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.