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.
Related
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.
I have read some of the questions and answers here, but it none match my situation exactly.
I want to keep all my fossil repos in a single place.
so I have
c:\Fossil_Repos\ with a repo for WebPages_Repo and another for Dev_repo etc etc etc
I would like to keep my original web pages and development pages in separated directories that are oustide of the Fossil_Repos directory, here is my structure
c:\Fossile_Repos\
c:\DevEnvironment\
c:\WebPageDevelopment\
This structure seems not to be unreasonable.
If from within my c:\Fossile_Repos\ I run the commands
fossil open Dev_Repo
fossil add c:\DevEnvironment
Then I see a listing of all the directories and files underneath c:\DevEnvironment, however I then go on to add
fossil commit -m "first deposit"
And get an error message on the first file saying the file doesn't exist. Note that the file path is correct (however it report the direcory as C:/DevEnvironment/firstFile.xml using the unix method of file separators)
Anyone got any thoughts on if I can do this or not?
thanks in advance
David
You can keep the repos wherever you like. However, you must issue the commands to fossil from inside the checkout.
So, in your example:
cd c:\DevEnvironment
fossil open c:\Fossile_Repos\repo_file_name
.. edit the files ...
fossil commit -m "first deposit"
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 am wondering if anyone has experience working on Django projects in a small team (3 in my case), using Git source control management.
The project is hosted on a development server, which is why I am having such a problem. Developers can't see if their code works until they commit their changes to their local repository, then push those changes to the server. Even then, however, git doesn't seem to be updating the files inside the directory holding the repository on the server - probably because it only stores the changes to save space.
We are beginning to tread on each other's toes when working on this project, so some kind of version control is required - but I just can't figure out an solution.
If anyone has overcome a similar problem I'd love to hear how it can be done.
When pushing to a remote repository, best results are when the remote repository is a "bare" repository with no working directory. It sounds like you have a working directory on the remote repository, which will not be updated by Git when doing a push.
For your situation, I would recommend that developers have their own testing environment that they can test against locally before having to push their code anywhere else. Having one central location where everybody needs to push their work before they can even try it will lead to much pain and suffering.
For deployment, I would recommend pushing to a central "bare" repository, then having a process where the deployment server pulls the latest code from the central repository into its working directory.
When you push to a (shared) git repository, it doesn't update that repository's working files. Basically because the working files might be dirty and in that case you'd have to merge--- and for that you need to have full shell access there, which may not be the case in general.
If you want to have the most recent "master" of the shared repo checked out somewhere, you can arrange for that by writing a post-update hook. I'll give an example of one below that I use to check out the "ui" subdirectory and make it available to Apache.
However, I will say that I think your process could be improved. Developers generally need personal servers that they can test on before pushing to a shared point: otherwise that shared repo is likely to be hideously unreliable. Consider, if I push a change to it and it doesn't work, is that my change that broke it or a side-effect of someone else's?
OK, I use this as a post-update hook:
#!/bin/sh
# Should be run from a Git repository, with a set of refs to update from on the command line.
# This is the post-update hook convention.
info() {
echo "post-update: $#"
}
die() {
echo "post-update: $#" >&2
exit 1
}
output_dir=..
for refname in "$#"; do
case $refname in
refs/heads/master)
new_tree_id=$(git rev-parse $refname:ui)
new_dir="$output_dir/tree-$new_tree_id"
if [ ! -d "$new_dir" ]; then
info "Checking out UI"
mkdir "$new_dir"
git archive --format=tar $new_tree_id | ( cd $new_dir && tar xf - )
fi
prev_link_target=$(readlink $output_dir/current)
if [ -n "$prev_link_target" -a "$prev_link_target" = "tree-$new_tree_id" ]; then
info "UI unchanged"
else
rm -f $output_dir/current
ln -snf "tree-$new_tree_id" "$output_dir/current"
info "UI updated"
title=$(git show --quiet --pretty="format:%s" "$refname" | \
sed -e 's/[^A-Za-z][^A-Za-z]*/_/g')
date=$(git show --quiet --pretty="format:%ci" "$refname" | \
sed -e 's/\([0-9]*\)-\([0-9]*\)-\([0-9]*\) \([0-9]*\):\([0-9]*\):\([0-9]*\) +0000/\1\2\3T\4\5\6Z/')
ln -s "tree-$new_tree_id" "$output_dir/${date}__${title}"
fi
;;
esac
done
As mentioned, this just checks out the "ui" subdirectory. That's the ":ui" bit setting new_tree_id. Just take the ":ui" out (or change to "^{tree}") to check out everything.
Checkouts go in the directory containing the git repo, controlled by output_dir. The script expects to be running inside the git repo (which in turn is expected to be bare): this isn't very clean.
Checkouts are put into "tree-XXXX" directories and a "current" symlink managed to point to the most recent. This makes the change from one to another atomic, although it's unlikely to take so long that it matters. It also means reverts reuse the old files. And it also means it chews up disk space as you keep pushing revisions...
Had the same problem, also working with django.
Agree to testing locally prior to deployment, as already mentioned.
You can then push the local version to a new branch on the server. Then you do a merge with this branch and the master. After this you'll see the updated files.
If you accidentally pushed to the master branch, then you can do a git reset --hard. However all changes not commited in the current working branch will be lost. So take care.