I tried to clone a repository to my home computer using Fossil scm, but instead of getting the folders, I ended up with a _FOSSIL_ file.
The steps I used were:
made a directory called Fossils
used fossil clone command which resulted in a .fossil file in Fossils
made another directory Work and used fossil open to open the .fossil file from Fossils.
This resulted in a file named _FOSSIL_ in Work.
Any ideas for what I'm doing wrong?
That looks perfectly normal. The _FOSSIL_ file indicates a checkout (aka work dir). If there's no other file in your Work directory, that means your repository is empty; or at least, that the branch you checked out (trunk by default) is empty.
What does fossil timeline show?
What occurs when you clone https://www.fossil-scm.org like:
fossil clone https://www.fossil-scm.org fossil.fossil
then
fossil open fossil.fossil
I have not heard of a FOSSIL file before. Try above step in its own directory and on more than one OS to see if the results are the same or similar to what you have now.
A sample way to use Fossil is very much similar to other VSCs, apart from the initial step of setting up a repository (either by init or by clone command.)
Generally, a Fossil repository is a database file (SQLite db). So init or clone commands create that local database (commonly given a .fossil extension). Some users prefer to keep all of the "fossils" in a separate directory (e.g. ~/fossils, ~/archive, ~/museum).
Once the fossil repository db has been created, it may be opened/checked-out into a working directory, in fact, as many directories as wanted (some users prefer to keep one work-dir per active branch). This is initially done with open command from within the working directory.
After that a user can do all of the familiar VCS operations, such as checkout or create branches, edit files, commit changes, pull/push etc.
In the working directory Fossil also creates its local config database (also SQLite), named _FOSSIL_ (Windows), or .fslckout (Linux).
So the sample flow to clone and open a remote repo could be:
mkdir ~/fossils
fossil clone <remote-url> ~/fossils/aproject.fossil
mkdir aproject
cd aproject
fossil open ~/fossils/aproject.fossil
fossil user default <my-remote-username> --user <my-remote-username>
fossil status
On Windows the sequence is effectively the same, just use path with backslashes and your user profile directory. By the way, Fossil commands accept Unix-style paths on Windows as well.
You may aslo be interested to checkout ChiselApp service which offers free public Fossil repositories; lots of various projects there to try to clone and contribute to, or create or own.
Of course, one may try to clone Fossil's own repo from the remote-url https://fossil-scm.org
More help from the official Quick Start guide.
Related
I am using CVS and I have this hierarchy:
/ROOT
/JAVA
/JavaProject1
/JavaProject2
.project
/PHP
/PHPProject1
/PHPProject2
.project
In Eclipse > CVS Repository Exploring, I can see this hierarchy and I can Check Out only the project that I want.
Also I can check out (import) JAVA and PHP folders (I created them as Eclipse General project for import) to Eclipse Package Explorer and can synchronize and commit all together.
When I want to use Git, it only supports one project.
I don't want a flat hierarchy (near all JAVA and PHP project together), I want to use tree hierarchy and I want to check out only the project that I want as with CVS.
Is my CVS hierarchy possible in Git or what technique should I use?
I think you're mixing what you want to do locally with how you want
to arrange things remotely. All git commands access only the local
repository. The 'push' and 'fetch' commands appear to access a remote
repository, but in fact they effectively start each other on the remote
machine running against the local repository on that machine. So the
tasks you can do remotely are very limited. Specifically, copying "branch"
and "tag" references and the commit histories those references point at.
This means for the simple case there is ONLY the local repository,
it exists in the .git directory in the working directory.
You can arrange working directories, with their .git directories however
you wish on your local machine. Likewise, you can arrange the the remote
repositories in any way allowed by the remote hosting service. The
layouts do not have to match. If the remote is your own Linux server you
can make the layout just like your local. If the remote is (for example)
Github you're more limited.
You'll need to backup the .git directory to backup
the repository; the rest of the working directory is probably not significant. You can use git push to do this backup, as long as you never use '--force'.
Git isn't really very keen on you having multiple working directories
for one repository. It is possible, however, in the simple case they
will each have their own copy of the repository and you will need to
push/pull the updates individually either to a "central" repository
or more "randomly". None of these repositories have to be physically
"remote".
Git much prefers you to switch between branches in one working directory
and use make install style processes to send builds out.
It is also possible to have unrelated branches in one repository, but most people find this too confusing as you still only have one working directory.
I just learned about LazyBones and absolutely love it! The problem is that it generates a "code skeleton" for you before your app's VCS repo exists. And I see there is some integration capability with Git, but what about other VCSes?
Specifically, I'm using Mercurial. So ordinarily, I'd create the hg repo for my new app (on the server), clone it out locally, and some code to the cloned working copy, commit & push it.
So I ask: what is the proper workflow (or set of commands) to create a new app from a LazyBones template and integrate it with a new hg repo?
I suppose, slightly more elegant way may be:
Generate skeleton by LazyBones in SomeDir
Init Mercurial repo after it in SomeDir
Add needed files from working directory into (empty) repository
Create remote repo on server
Add remote repository URL into [path] section of local repo's .hgrc (maybe also auth. credential into [auth])
Push
I've got Composer installed and I've used it to download HTMLPurifier locally. Now I'd like to push that download to my OpenShift Git repo. So, in a Git Bash window, I run the following...
git add -A :/
git commit -a -m "Uploading HTML Purifier"
git push origin master
At this point Git reports that the push was successful but when I ls the directory through SSH, it shows that the HTMLPurifier directory is empty. Why is that? How do I get Git to push those files?
Additional Info: I noticed that the HTMLPurifier directory is indeed a Git repo itself and contains a .gitignore file in its root directory. I tried deleting it and re-running the above commands but to no avail...
You should try to avoid pushing downloaded dependencies into a repository. It is recommended to add the vendor directory into the .gitignore file at top level. But what you must do instead is commit and push both composer.json and composer.lock.
Here's why: The vendor directory is managed by Composer. Running Composer will probably do minor things during an update, but may also be doing heavy stuff if the Composer team decides to optimize things.
Also, if you require a branch of a package, and Composer knows the repository of that package, it will default to cloning a Git repo or do a SVN checkout instead of trying to grab a ZIP package of that branch (often there is no way to get such a package for branches, and even tagged versions in a plain Git repository do not have such download ability. Composer knows that Github offers such downloads, and detects Github by looking at the repo URL.)
So you can assume that Composer will put a lot of repository meta data into the vendor file, and if you blindly commit these, things will get ugly. First of all, you are committing way too many files, increasing your repository by an unnecessary amount, which will slow down things. Then, if cloning Git repositories, these will be treated as submodules, and that has another bunch of nastiness I am told. If you are just learning Git, it probably isn't a good idea to start with these. And if you are sufficiently known to the tools (Git and Composer), you probably won't need them either.
There really is only one reason why you'd try to commit a modified version of the vendor directory: If your release process is completely depending on all files being present in your one repository, without any way to run a composer install during the release to make these files appear on the target server.
In such cases, you'd install or update the packages with Composer, and then go through all created directories and delete any .git and .svn (and probably also .hg for Mercurial) folders you encounter. Only then you'd be able to commit the files into your own repository.
But note that this step might be a tedious step to do manually - you probably want to create an update script that does all that work for you. You also might run into issues when updating dependencies because Composer expects files to simply go away when deleted, and not be in the way when being written. I cannot tell you exactly what you'd be experiencing because it depends on how you'd do stuff, but I expect you stumbling upon random puzzling issues.
Bottom line: Avoid committing the dependencies into your own repository if possible.
Try using the -force option, you will also most likely need to delete the .git directory inside the HTMLPurifier directory too.
I am following this tutorial on establishing the ssh communication.
Everything goes fine until I get to:
Step 7. Change your repo from HTTPS to the SSH protocol
I have no idea what the first step means. I have no .hg folder and if I create one using hg init, there is no hgrc file in it.
I came to a new location and I want to clone repositories from Bitbucket using ssh to start working.
Also I have no idea what is meant by myquotefork. It does not appear in the previous text.
If you simply just want to clone an existing repository from Bitbucket using SSH instead of HTTPS, that is quite simple. From the command line on your local computer (where you want the repository cloned to), write the following command:
hg clone ssh://hg#bitbucket.org/claims/nodatime
You will now have the repository cloned to the nodatime folder. And inside the nodatime folder, you should also have a .hg folder containing a hgrc file with the content described in point 3 in your question.
I haven't read the tutorial you're following, but point 1 expects that you've already cloned an existing repository. The .hg folder is created when you initialize/clone a repository. The hgrc file inside this folder is however only created when you clone an existing repo (and not when you just initialize one), which is probably why you didn't see it.
You may classify my question to the layman's level, but I am using Git for the first time (til now I used TortoiseSVN) and I am not sure how I can check out an existing project from a server, so as to have it available on my local machine in a folder. I have installed Git Bash. Should I run it (Gui), select New Archiv and then specify the path of the project in the server? Is there a better Git framework to install, which is appropriate to make the same task more easily?
I would appreciate also some screenshots if needed in the answers.
Update: I have installed also TortoiseGit. I want to create a new clone by a right click in a directory, but the new Clone is not available after the right click. Does it need additional configuration? If no, what should I do from TortoiseGit to checkout an existing project?
I'd usually recommend learning git from command line. But if you are already familiar with TortoiseSVN then TortoiseGIT is a good tool for you.
Also, I think you should learn git very well. I can recommend the book Pro Git.
To "check out" a git repository is called clone in the git world (you will get a whole copy of the server repository). This can be done either from command line or TortoiseGIT.
git bash:
$ cd /path/to/my/projects
$ git clone url-to-server-repo
Update:
Since you get the "normal" TortoiseGit menu (without clone option), it seems you already have a local git repository. You probably created an empty git repository by mistake. Look for a hidden directory .git in the project directory or any parent directory.
right click on the folder (not right click on nothing in the folder, the icon of the folder you want to clone INTO from the parent directory) and select clone from the menu.
FYI:
clone = create a copy of a repository.
checkout = change the current state of an existing repo to a saved state.
so if you have a repo w/ 3 commits (A,B,C) when you clone the repo you will be at the most current state (C). if you want to see the previous state of the repo you would git checkout B. if you want to see the repo's initial state you would git checkout A
hope that helps.