I need to put under version control sparse files.
I mean files like:
/etc/hosts
/opt/Sybase/config.ini
/usr/local/httpd/conf/httpd.conf
They are sparse in the sense that they are not in one single folder.
Git usually works in a single folder. Other version control tools do the same.
I need to put these files under version control because I need to track the entire configuration of a server.
Fossil allow to add single file and do not track the whole dir of it
Somehow tricky, but
Create new repo (or repos, if you have more than 1 LT in next step)
Define common base dir(s) for your files - it will be place of "permanent" Local Tree (common dir is important, because Fossil doesn't allow add files to repooutside open tree)
Open repo in this CommonBase
Add files
Commit
After it you can open repo in any other location into "working" Local Tree, get all files in it, edit-commit, but don't forget "update" after commits your "permanent" Local Tree
HTH
Related
I just got started with fossil. My reasons for selecting fossil are:
cross-platform
single exectuable
single repository file (typical extension .fossil)
supposedly easy to use (but aren't they all?)
I have several questions. Context: Suppose I want to keep track of changes to every file inside several directories, aptly named dir1, dir2, etc. Suppose I want to keep a copy on a USB stick. Suppose I want to keep a copy on another partition of the same disc as I move back and forth between Linux and Windows partitions. I'm the only user and may not always have access to the internet.
I would like to store dir1.fossil outside of dir1. Can I do that? The user-manual instructions tell me to create dir1.fossil from inside dir1, and that's where the dir1.fossil are currently created in my setup. Ideally I'd like my dir1.fossil, dir2.fossil, etc. files to be stored together in another directory, e.g. named fossilreposdir and located at the root. Possible?
I would like to stick a usb flash drive into my laptop and push/pull repositories from it in a plug-and-play manner.
If possible I would also like to push/pull repositories across my windows and linux partitions without using the usb stick.
If setting it up is too much of a headache (for my poor head), I will resort to simple copy-pasting of the .fossil repositories back and forth.
Yes.
Yes.
What DO you want to use? Me, I use dropbox to hold my repositories. Then every machine registered with dropbox has access to all my repositories.
// into working directory
cd ../dir1
// create repository somewhere else
fossil new ../fossilreposdir/test.fsl
// open remote repo in local working directory
fossil open ../fossilreposdir/test.fsl test.fsl
// add files
fossil addremove
// commit
fossil ci
I am working with a CVS repository found on a remote server.
I check out the code to a local directory code_local
Then I copy code_local, into code_local_2
Do I have now two independent local copies of the repository? Can I change files, commit, update etc. on each directory independently, is if it was done form two different computers?
(this may depend on the way CVS stores information about a local copy)
Yes I do know it's not a straight forward use of CVS, just asking if it will work
Do I have now two independent local copies of the repository?
Yes you have two independent LOCAL copies.
Can I change files, commit, update etc. on each directory
independently?
No, both copies point to the same file on the same repository. so they are independent as long as you haven't committed them. when committed the last commit operation will overwrite the previous one.
in fact there is a CVS folder beside every folder of your code that keep repository information of files inside that folder. so when you copy a project or a package, the CVS folder will be copied along with, so the same repository entries will be referenced, no matter how many copies have you made.
Even if you past the copied folder to another package hierarchy, whenever you commit the files it will replace the original files in repository where it first created.
If you want to have independent copies you have to copy and place your source code (.java) files only and commit it through Eclipse for example, in this case the CVS plug-in doesn't find any existing CVS folder beside the new folder and generates a new one in the local and new entries in the repository.
I've repos with various configuration files, like .vimrc, _vimrc (for windows), or .bashrc. I'd like to create one repo that holds all of them, so I can easily set up my environment on clean machines. I'd like linux / windows specific files to be in different branches (?), so that cloning on linux would not download windows files.
How do I do that, assuming all existing repos are on github and the resulting repo should be on github too?
Is there a way to force git to just download files from a branch and save them in a directory, without creating a local repo? For .bashrc it'd be faster to just download and save to ~, instead of cloning and then copying that file to home dir.
Maybe something like dropbox would be better for this?
My question is similar to this one but for Mercurial (converting using cvs2hg). However there some differences. This is part of our CVSROOT/modules file and shows the problem nicely:
PD1 -a PROD/PD1/Drivers Drivers/PD1/Firmware KernelHeaders Shared IppLibs
PD2 -a PROD/PD2/ Drivers/PD1 KernelHeaders Shared IppLibs
#PD2Linux Driver
PD2Linux PROD/PD2/Drivers/Linux/BuildFiles &PD2LinuxSource
PD2LinuxSource -d src &PD2 &PD2LibUSB
PD2LibUSB -d ThirdParty/libusb libusb
As you can see the driver structure is complicated. We're definatly looking to rationalise the driver structure, rather than including the entire older driver (PD1) in the newer one.
As I understand it, in Mercurial you can use the share extension to do the sub directory mapping.
My questions are
Is there a way in Mercurial to bring files located further down in the directory tree (in this case the autoconf files) upto the root as is done in the first line of the PD2Linux Driver?
Is there a way to create directories, as per the -d flag?
How to merge changesets that span PD1 & PD2?
e.g. if changes were made in PD2 that spanned both drivers and checked in to PD in CVS. This is bit of long shot as CVS doesn't have changesets.
I wonder if the cvs2hg takes into account the CVS modules file?
Atm I converting each PD directory individually (creating a cvsroot in each subdir), would it better so convert them all together and then split up them into seperate hg repos?
You write:
As I understand it, in Mercurial you can use the share extension to do the sub directory mapping.
Not quite. The share extension let's you associate several working copies with a single repository — it's not about remapping (sub-)directories.
Is there a way in mercurial to bring files located further down in the directory tree(in this case the autoconf files) upto the root as is done in the first line of the PD2Linux
Driver?
The answer to this and your other questions is: no. The core problem is that Mercurial (and other distributed version control tools) requires you to checkout the full repository every time. You cannot just clone repo/some/dir/, you must always clone repo/.
Atm I converting each PD directory individually (creating a cvsroot in each subdir), would it better so convert them all together and then split up them into seperate hg repos?
The end result should be separate Mercurial repositories — precisely because you need to clone the full repository. So make sure to make a 1–1 mapping between repositories and your drivers.
One tool that you might find useful is subrepositories. A subrepository is a nested repository that Mercurial will checkout when you clone the outer repository. The come with a number of caveats, but big companies are using them today (I've helped a number of companies with setting up subrepos).
I have a directory structure like:
project_root
data/
src/
.hg/
utils/
math/
graphics/
...
README.txt
LICENCE.txt
As you can see from the location of .hg/, only src/ is under Hg control. I'd like to move the repository root up from src/ to its parent directory project_root, so I can track data/, README.txt, and LICENCE.txt as well.
A hacky way to do this would be to move everything down a directory rather than moving .hg up:
Move the contents of src down to a new directory src/src/
Move the contents of project_root (other than src/) down to src/
Rename src to new_project_root
Move new_project_root out of project_root, delete project_root
Is there a better way? I can't be the first person with this problem, and the above solution seems overly involved.
You should try hg convert. You will be "converting" your existing Mercurial repo into a new one. You specify rules for the conversion, which in your case will be that all files from the original repo go to a src directory in the new repo. Then you can manually copy and hg add the other files to the new repo.
This has the advantage that it won't be reflected as separate changes in your history. The possible disadvantage is that it will cause your changeset IDs to be regenerated, and existing clones will no longer be able to pull from the new repo.
Your plan is fine. It may seem involved, but it should take less than 20 minutes (worst case) and only happens once.
In the first step when you move the files that are tracked, you should use hg rename (alias hg move) to move them, as Mercurial will remember what each file was before and after the move. This will help with merging changes on file prior to the move with the new files after the move. Works best when renaming/copying is not accompanied by changes to the contents in the same changeset.
I recommend cloning the actual repo (or copying the entire project directory) before proceeding.
hg's Detect Renames works a treat nowadays.
Clone the repo so that you can mess things up without worry.
Using your example:
create the src/src subdir
move utils, math, graphics etc into src/src
Then open the commit window.
the moved files will appear in their old directory with a ! and in their new directory with a ?
right click on any file and choose "Detect Renames..."
slide the Min Similarity slider to 100%
Click the Accept All Matches button, and close the Detect Copies/Renames window
the moved files should now appear with an R in the old directory and an A in their new directory
commit this change
Then I moved data, Readme.txt etc down into src (not src/src)
committed the adds.
Finally, now that I have the repo as I want it, push the changes back to the originally cloned repo. Don't forget you'll need to Update the original repo to see the changes in the working directory.