I'd expect this to be explained in the beginner's quick start guide, because almost everyone who starts with fossil will have projects that he wants to start managing with fossil. Yet I could not find an explanation anywhere in the documentation.
(I'm coming from git, which was way too heavy for my needs, but at least creating a new repository in an existing folder was easy ...)
(tried to answer my question but have insufficient reputation. so here it is:)
I think I figured it out myself. Here's what I did, for beginners:
Create directory for repositories, C:\www\fossil
Enter fossil directory
fossil init projectname
Enter directory of existing project C:\www\projectname
fossil open ../fossil/projectname
fossil add *.*
Some comments:
Step 3. can be alternatively done with fossil new instead of fossil init.
Step 6 should be fossil add .; this is recursive. fossil does not abide by the old, Microsoft rule that states *.* means every single file even without extension. fossil add *.* will merely add all files and directories that contain a dot in their name.
Step 7 should be fossil commit -m "Initial contents of my project"
Related
My question is very similar to Retaining svn copy history when converting to git except that I am using the free kde svn2git tool
To summarize:
I'm trying to convert a single SVN repo over to a single git repo.
After migration of the svn repository to git I have noticed that git does not seem to follow svn copy operations so the resulting history is much briefer than I expect. Suppose my SVN repo looked like this:
root
a
b
c
parent project
b
c
Projects b and c were recently copied under parent-proj as part of a restructuring effort with the intention of eventually deleting them from their old locations under root. After migration the resulting git repo is missing all of the history that originated from /b and /c before the move.
I am using the kde svn2git tool which can be found at https://github.com/svn-all-fast-export/svn2git
I tried to look at the sample rules files and documentation for this tool but could not find any information on how to achieve this using this tool.
In my experience the situation you describe is a frequent occurance in SVN. People create an 'arbitrary trunk'.
Ideally projects should follow the Subversion conventions. That means that each project will have a subfolder called 'trunk, branches, tags'. Then when migrating with svn2git all you need is a rule for those three folders:
create repository fw
end repository
match /Project/trunk/
repository fw
branch master
end match
match /Project/branches/([^/]+)/
repository fw
branch \1
end match
match /Project/tags/([^/]+)/
repository fw
branch refs/tags/\1
end match
Unfortunately, if you are migrating a repository which didn't strictly follow the convention, then you can have arbitrary trunks, which means a completely separate history. So you need a separate rule, for example you might have a rule like this:
match /Project/trunk/subdir1/subdir2/myproj/trunk
repository fw
branch master
end match
You may need to write a script examine the svn paths, which generate rules based on paths discovered.
I recently started working with SVN, I am using it in combination with Wordpress.
I just made a number of updates to Wordpress and to some plugins, and I would like to know in what order I need to update, or whether it even matters.
Here is what I did:
Locally on my computer:
svn delete folder xyz
commit the deletion
add a new folder by the same name
svn add the folder
svn commit
Now if I log in to our development server, do I just to "svn update" ?
Or do I need to go through the various versions by updating to specific version numbers?
The reason I ask, is because I have had one or two tree conflicts in the past where I got:
Tree conflict (local dir unversioned, incoming dir add upon update) for location wp-content/plugins/ExamplePlugin/ExampleSubDir
Does my workflow lead to such errors? Am I overlooking something?
Your workflow is fine, and yes, you would just perform a single svn update on the other computer to get fully up-to-date.
The workflow you describe would produce a tree conflict if you happened to have an unversioned folder named "xyz" in the same location as the one you just committed (which is what the error says in the parenthetical remark). You should remove that unversioned folder and then let SVN add that folder itself (via the call to update).
If you haven't already, it might be worth reviewing some of the documentation to ensure you understand the fundamentals.
I want to create a master repository on our server, from which I can clone a local version onto my computer.
I am using R Studio v0.98.994.
So far, this is what I have tried doing:
Create a folder for the master repository to live in. I do this using 'new project' in R studio, and tell it to make a git repository.
I can then open up another new project, located on my C drive, and use R studio to clone, by telling it to open an existing project and setting the URL as the location of the master project.
However, then when I make changes and commit to my local repository (which works fine) I cannot push to the master repository, I get an error exactly as described in this question: git push fails: `refusing to update checked out branch: refs/heads/master`
So it appears that R Studio creates non-bare repositories?
Now I thought, well okay, I will use git bash to initialise the repository and then connect to that within R studio.
I do so, but cannot then find a way to use that repository in R Studio.
I am very new to Git, so it is entirely probable that this is one of those 'read the instructions' questions, in which case I am very sorry - and could someone possibly point me towards some guidance for this situation? I have spent the better half of a day googling around this error and haven't yet managed to pull together the pieces :( I also apologise; this doesn't feel like a very reproducible question.
It sounds like you are using Windows Git, with a setup on a local Windows machine (C: drive) and a server of some kind, mounted as the S: drive. There's a few things you should be aware of when doing this.
Shared Repositories
If you are intending for multiple people to share the same repository, you want to initiate a shared repository. See the --shared option in git-init for more details. Note that I'm not sure how having your repository on a Windows machine affects the sharing options. If you are just trying to keep your repository in two places, that makes things a lot easier.
Bare Repositories
Separate from the discussion of sharing is the discussion of bare repositories. If you don't intend to ever work with files in the server (i.e. it's just going to be a place to push changes so they are safely stored), you could initialize a bare repository. A bare repository contains the database structure of Git, but does not have the actual files in the directory.
A standard Git repository is a directory with a hidden folder in it named .git. This .git folder contains all the various data structures that Git uses to track changes. A bare repository is essentially a folder containing only the contents of .git.
The good thing about a bare repository is that no one can work in the repository itself (since there is no working directory, just the database). This means that no one could log into S: and edit the repository themselves. Instead, they would have to clone the repository, then push their changes back to the origin. The GitGuys have a good article about why this is ideal.
Note that shared repos and bare repos are not dependent or mutually exclusive. As a general practice, if you are having a "server repo" from which you pull and to which you push, you should have it be bare, regardless of whether the project is shared.
A Non-Shared Workflow
Since it's not clear if you are sharing or not sharing and you're on a Windows environment, which I don't know about from a sharing standpoint, I'm going to give you a simple example. Using git-bash, you should be able to change directories to wherever on S: you have your repositories. Then, use git init with the bare options as described by the link above to initialize a bare repository. Navigate to where you want your repository to live on C:, and then do git clone to get a working copy.
Add a README file or something else so you can do your initial commit, and then commit and do git push origin master to push your changes to the S: repository. Once all that is done, THEN initialize the RStudio Git project. RStudio should defer to your existing configuration, and things should hopefully work.
As a new user of Fossil, I'm curious if there are any negative implications with using Fossil to store things like /etc/, /usr/local/etc files from Unix like systems like FreeBSD & OpenBSD. If I'm doing this for multiple systems, I think I'd create a branch with each hostname to track those files.
Q1: Have you done this? Do you prefer a different VCS to handle the system files?
Q2: Lots of changes have happened in Fossil over the years and I'm curious if it's possible to restrict who can merge branches with trunk. From reading earlier threads it wasn't possible but there are two workarounds:
a) tell people not to merge to trunk
b) have people clone and trunk maintainer pick up changes from their repo
System configuration files stored in /etc, /var or /usr/local/etc can generally only edited by the root user. But since root has complete access to the whole system, a mistaken command there can have dire consequences.
For that reason I generally use another location to keep edited configuration files, a directory in my home-directory that I call setup, which is under control of git. Since I have multiple machines running FreeBSD, each machine gets its own subdirectory. There is a special subdirectory of setup called shared for those configuration files that are used on multiple machines. Maintaining multiple copies of identical files in separate repositories or even branches can be a lot of extra work.
My workflow is the following;
Edit a configuration file in my repository.
Copy it to its proper location.
Test the changes. If problems occur, go back to step 1.
Commit the changes to the revision control system. Copy the
committed files to their proper location.
Initially I had a shell script (basically a list of install commands) to install the files for me. But I also wanted to see the differences between the working tree and the installed files.
So for my convenience, I wrote a script called deploy to help me with this. It can tell me which files in the repo are different from the installed files and can show me the differences. It can also install files to their proper locations.
I'm trying fossil for the first time, and messed it up within minutes. I created a repository, then apparently ran commands in the wrong folders etc., eventually deleted the test repository, in order to restart. (Somewhere I had read that fossil was "self contained", so I thought, deleting a repository file would be ok. What is the correct way to delete a fossil repository?)
Now, with almost every command I try (incl. "all rebuild"), I get the error "not a valid repository" with the deleted repository name.
What now?
According to this post:
The "not a valid repository" error only arises
when Fossil tries to measure the size of the repository file and sees that
either the file does not exist or else that the size of the file is less
than 1024 bytes. It does this by calling stat() on the file and looking at
the stat.st_size field.
it seems likely that you have a missing or truncated Fossil file. Make sure you've actually deleted the repository file, and that your filesystem has actually released the file handles. Fossil stores some respository information in ~/.fossil, so you may need to remove that too.
rm ~/.fossil
In egregious cases, you may want reboot after deleting this file, just to be sure you're working with a clean slate.
If you're still having problems, try creating a new repository file in a different directory. For example:
cd /tmp
fossil init foo.fsl
fossil open foo.fsl
fossil close
If all that goes smoothly, you'll have to hunt down whatever remnants of the repository are lurking. As long as the file handles are closed, there's no reason you shouldn't be able to delete foo.fsl (or whatever) and call it good.
I have just experienced the exact same problem on Windows. I too seem to have found a solution. Here is what I did. I cannot guarantee that it is a universal solution or even a good one. In:
C:\Users\mywindowsusername\AppData\Local
There was a file named _fossil and a directory/folder named VirtualStore. I deleted both. This seems to have removed all traces of the repository. Note that the repository was still in the "open" state, as with your case.
Edit: After experimenting further, it would appear that VirtualStore is a temporary directory that will disappear after committing (a .fossil file will then appear inside the targeted directory).
My mistake was to create a repository at the root and clone: fossil proceeded to clone the entire C drive. Probably a common newbie mistake.