The problem is pretty straightforward, I'm just not very well-versed in these tools (or CVSes in general).
Each branch of the project contains 4 folders:
branch-1
folder1
...
folder4
branch-2
folder1
...
folder4
...
folder4 is ginormous (~2GB), contains things I'm usually not interested in, and I'd rather not download it every single time -- it takes forever, and takes up space.
I see that the "Checkout from SVN" dialog has a Depth field, with options:
Fully recursive
Immediate children, including folders
Only file children
Only this item
None of these options is quite what I want. 1 and 2 will still download folder4, while 3 and 4 will omit everything.
Ideally, I'd be able to simply omit folder4 from the download initially, with the option to pull it down later. I don't mind seeing it as an incoming change (and simply ignoring it) during sync operations.
Any ideas? Am I missing something?
P.S. I tried to post this question in Super User, but the site is giving me real problems.
Yes, you can do this using Subclipse:
Check out using the "Immediate children" option. folder1, etc. will be empty.
Select the empty folders (except folder4) in the newly-checked out project.
Choose Team → Update to Version...
Set the depth to "Fully recursive".
Tick "Change working copy to specified depth".
Click OK.
Another way to do this involves the svn command line client:
Check out using the "Only this item" option. The top-level directory will be empty (folder1 etc. will be missing).
cd project-dir
svn up folder1 folder2 folder3
Related
In our development environment, we have certain files that are autogenerated by some parsing tools, and they should never be merged from one branch to another. We do have them under source control, however, so that only one user needs to run the generation tool for any given branch; all other users will get the generated files automatically.
Is there a way to tell "findmerge" to skip these files when it traverses the VOB? If findmerge cannot resolve the differences in a file, it loads the default diff tool so the user can resolve the differences manually. For these autogenerated files, this is a waste of time; the user just has to cancel it and then run the autogeneration tool when the findmerge is complete.
If it matters, we use dynamic views.
You might consider the same approach as with binary files
Your project manager can overcome this problem by creating a special element type for the binary file type and specifying one of the following mergetypes:
never: A merge or findmerge operation ignores versions whose element type has never as a mergetype.
So, as in this page, something like:
cleartool mkeltype -supertype file -mergetype never -nc FILE_NEVER_MERGE
And then, in the folder with your generated files (here for instance for XML files):
ct find path/to/generated -type f -ele "{eltype(xml)}" -exec "cleartool chtype -force FILE_NEVER_MERGE %CLEARCASE
I am using Eclipse (this is probably irrelevant) and I want to exclude Maven target folder from commit.
There are lots of notations
/target/**
*/target/*
/target/**
target/
/target/
What is the difference?
And what is the exact meaning of each of them?
TL;DR: you probably want /target/.
Long
Let's start with a clear definition of the work-tree (from the gitglossary, where it is spelled working tree):
The tree of actual checked out files. The working tree normally contains the contents of the HEAD commit’s tree, plus any local changes that you have made but not yet committed.
We need to keep in mind that what Git stores, and exchanges with other Git repositories, are commits. Each commit freezes, for all time, some set of files so that at any time in the future, you can tell Git get me commit a123456... and get all your files back as of the time you made commit a123456.... (Each commit has a unique, big-and-ugly hash ID like this, which you'll see in git log output and elsewhere.)
Commits vs the work tree
The files inside commits are stored in a special, Git-only, compressed, de-duplicated, and read-only form. I like to call these files freeze-dried. They literally cannot be changed. So they're fine for archival, but completely useless for getting any actual work done. Git therefore needs to be able to extract any given commit, "rehydrating" the freeze-dried files and turning them back into ordinary everyday files that you can see and use and work with. The place you put these files is the work-tree or working tree.
The working tree of course has a top level directory (or folder if you prefer that term), in which you store various files, including your main .gitignore file. That top level directory can have sub-directories (sub-folders) and each sub-folder can have its own .gitignore file too. This is important when you ask about /target vs target, for instance.
Gitignore entries
An entry in a .gitignore file can be in any of the following forms:
name (with no special characters like *)
name.* or *.txt or even name*txt
folder/
folder/*
folder/name
folder/name*txt or any of these variants
folder/subfolder/
folder/subfolder/*
any of the above prefixed with a slash, e.g., /name or /folder/ or /folder/name
any of the above, including prefixed-with-slash, that are then also prefixed with !, e.g., !/folder/name
This is not meant to be an exhaustive list (you have listed several other forms), but rather to illustrate a few basic principles:
A simple file name means any file or directory with this name.
A name suffixed with a slash means any directory (folder) with this name. Entities that are files don't match this kind of entry.
Entries can have embedded slashes—slashes that are not at the front, and not at the rear, such as folder/name.
Entries can have leading slashes, such as /name or /folder/, or both leading slashes and embedded slashes, such as /folder/name.
Entries can have glob characters, * and **, in various places.
Entries can be prefixed with !.
The rules for gitignore entries get pretty complicated, but start out simple enough. Remember that the .gitignore could be in the top level folder of your work-tree, or in some sub-folder!
A plain name, with no embedded or leading slashes, matches any file or folder anywhere from this folder or any of its sub-folders.
A slash-suffixed name, with no embedded or leading slashes, matches any folder (but not file) from this folder or any of its sub-folders.
If an entry has a slash prefix or an embedded slash—either one suffices—the entry matches only files and/or folders in this folder. Hence folder/name and /folder/name mean the same thing: match a file (or folder) named folder/name in this folder—i.e., the place containing the .gitignore file. Do not match the file sub/folder/name, for instance.
If an entry ends with a trailing slash, it only matches folders (regardless of anything else).
You said:
I want to exclude Maven target folder
This requires answering a sub-question: Where does this Maven target folder exist? Is there only one such folder, or can there be target/ entities in sub-folders? (There's also a separate issue, which is that .gitignore directives don't mean quite what people think they mean, and that you need to pay attention to what's in your index, but we'll leave that for another section.)
If this means: Don't include anything in target at the top level of my work-tree, but do go ahead and include, e.g., files named sub/target/file then you should use:
/target/
as the full rule in the .gitignore in the top level of your work-tree. It's slightly redundant since you already know that /target is a folder, but it expresses clearly that you want to ignore the folder named target in the top level of your work-tree.
If this means: Don't include anything in build-artifacts/target/, then you can put:
build-artifacts/target/
or:
/build-artifacts/target/
into the top-level .gitignore; or you can put:
/target/
into build-artifacts/.gitignore. The one in build-artifacts/.gitignore needs a leading slash because /target/ has no embedded slash, while the one in the top level .gitignore does not require a leading slash because it has an embedded slash.
If, on the third hand (first foot?), the requirement is to ignore all files in any folder whose folder-path contains a target component—e.g., you not only want to ignore target/file but also sub/target/file2 and sub/target/sub2/file3—then you should use:
target/
as your .gitignore entry, probably at the top level of your work-tree.
The role of the index / staging-area
The .gitignore files are about things in your work-tree, but Git does not build new commits from your work-tree. Instead, Git builds new commits from an intermediate thing that it calls, variously, the index or the staging area. (These two terms refer to the same entity.)
While the index has some other roles, its main one, especially for our purposes here, is that it holds a copy of every file from the original commit you extracted, or an updated copy or a totally new file. That is, if you extracted a commit that had just the two files files file1 and folder/file2, your index would now have copies of file1 and folder/file2 in it.
The copies inside the index are in the same freeze-dried format as the copies inside a commit. The difference is that you can replace the copies in the index—or add to them, or even subtract them away. That is, you can run git add file1 to take the useful version of file1 in your work-tree, freeze-dry it, and stuff that into the index. You can do the same with folder/file2, and you can put new files like folder2/file3 or ./file4 too. What git add does, in short, is to freeze-dry the work-tree version of the file and stuff it into the index.
When you run git commit, Git simply packages up everything that's in the index right then and make the new commit from that. So that's why you have to git add files all the time: every time you change the work-tree copy, you need to update the index copy, otherwise Git won't save the new version: Git will just re-save the old version again. (To save space, commits that save the same version of an old file really just re-use the old freeze-dried file. They can do that because these files are read-only. It's always safe to locate an old copy and re-use it, because by definition, everything inside Git is frozen for all time. Only the index and work-tree copies can be changed!)
In other words, you can think of the index as the proposed next commit. You copy files into it to update the proposed next commit. To remove a file entirely from the proposed next commit, you use git rm --cached or git rm (without --cached): Git will remove the file from the index, and maybe from the work-tree too, and now your proposed next commit just doesn't have the file at all.
A file can be in the index / staging-area and in the work-tree. That happens all the time. Such a file is called tracked. The contents don't have to match: it's just the fact that the file is in the index right now, and also in the work-tree, that makes the work-tree file tracked.
If a file is tracked—if it's in the index right now—then nothing you do with a .gitignore will affect it at all. To make it not tracked, you have to remove it from the index.
If you remove the file from the index—or if it's already not in the index now because it wasn't in the commit you checked out earlier—then the work-tree copy is untracked. Now the .gitignore entry matters. The .gitignore entry tells Git:
Don't complain about this file. Normally, git status would whine at you, telling you that the file is untracked and, gosh golly gee, shouldn't you git add it? The .gitignore makes Git shut up about that file.
Don't automatically add this file. If you use git add . or git add * or something like that, you're telling Git: add everything. The .gitignore modifies this to be: add everything—except these untracked files that are also ignored, don't add those!
It has a third effect, which is to give Git permission to clobber the work-tree file in some (rare-ish) cases, and to change the way git clean works with -x and -X.
Really, the file should not be called .gitignore, but rather something like .git-dont-whine-about-these-files-and-do-not-auto-add-them-either-and-maybe-occasionally-do-clobber-or-clean-them. But who wants to type that in all the time? So, .gitignore.
Conclusion
There is even more to know about .gitignore entries, but this is already long enough (maybe too long). The summary version is:
.gitignore only affects untracked files;
it's mainly about shutting up whining, and avoiding auto-adding; and
use a trailing slash to mean directory / folder (whichever word you prefer) and a leading slash to mean as found in this directory. When you have complex entries (with embedded slashes), the leading slash is redundant, but conveys your intent.
If you don't want the leading-slash effect, but do need embedded slashes, you either have to distribute your ignore entries to sub-directories / sub-folders, or use the ** notation (as a leading component) to match any number of path components. Otherwise there's rarely any need for ** at all.
Not covered here: once Git realizes it doesn't have to read a work-tree directory, it doesn't bother reading it. As a result, ignoring a subdirectory generally makes it impossible to un-ignore (with ! rules) anything within the subdirectory.
My original problem is that I have a directory where I write various scripts. Each of them is independent of others, and usually one-file-long. I want to have some versioning applied to them, but I have the following problems/requirements:
I don't want to have to store each small script in a separate directory!
I don't want to store them all in one repository OTOH, as they are completely unrelated, and:
some of them may later grow to more files (and then they will need a separate dir),
I sometimes want to copy one of them to a different machine (and I want to clone the whole repo).
I want to benefit from (distributed) version control mechanisms -- at least:
"infinite" number of revisions,
ability to clone repositories on different computers,
ability to do "atomic" multi-file commits.
Is it possible?
I'd prefer to do it in some mainstream distributed VCS (a solution using Mercurial would be preferable, but I'm not fixed).
EDIT: the solution has to be free (at least "as in beer") and cross-platform (at least Win32 & Linux).
Related, but didn't help:
"two-git-repositories-in-one-directory" -- didn't find it helpful: the accepted answer looks like point 2. (above) to me; the current "community voted" answer sounds like 1.
"Version control of single files using Subversion" -- also too much of 2. or 1.
These requirements seem pretty "special" to me, so here is a solution on par with them ^^
You may use two completely different VCS, in the same directory. Even two "instances" of SVN might work: SVN stores its metadata in a directory called .SVN and has (for historical reasons regarding ASP) the option to use _SVN. The Directory listing should look like this
.SVN // Metadata for rep1
_SVN // Metadata for rep2
script1 // in rep1
script2 // in rep2
...
Of course, you will need to hide or ignore the foreign scripts or folders from each VCS...
Added:
This only accounts for two scripts in one folder and needs one additional VCS per script beyond that, so if you even consider this route and need more repositories, rename each Metadir and use a script to rename it back before updating:
MOVE .SVN-script1 .SVN
svn update
MOVE .SVN .SVN-script1
Why don't you simply create a separate branch (in the git sense) for each (group of) script(s)?
You can develop them individually as you please. Switching to a branch will show you only the scripts from that branch. It's sort of like directories but managed by the version control system. If you later want to pluck a branch out into another repository, you can do that and if you want to combine two scripts into a single project, you can do that as well. The copying them to the different machine point might be a problem but you can clone the branch you're interested in and you it should work for you.
Another proposition for my own consideration is "Using Convert to Decompose Your Repository" article on hgtip.com. It fails as a "standalone" solution, but could be helpful as an addition to the "mv .hgN .hg / MOVE .SVN-script1 .SVN" idea.
You can create multiple hidden repository directories and symlink .hg to whichever one you want to be active. So if you have two repositories, create directories for them:
.hg_production
.hg_staging
Then to activate either of them just do:
ln -sf .hg_production .hg
You could easily create a bash command to do this. So instead you could write something like activate-repo production, which would run ln -sf .hg_production .hg.
Note: Mac doesn't seem to support ln -sf so instead you'll need to do:
rm .hg; ln -s .hg_production .hg
I can only think of these two lightweight versioning systems:
1) Using Dropbox with the Pack-Rat upgrade, to keep a full history of versions for each file automatically backed up and with the possibility to be shared with multiple Dropbox users: https://www.dropbox.com/help/113
If you have multiple machines managed by the same user (you), the synching would be automatic. Also if the machines are in the same LAN, Dropbox is smart enough to sync the files over the local network, so big files shouldn't be a worry.
2) Using a 'Versions' aware text editor for Mac OS X Lion. I'd expect TextMate, Coda and other popular Mac code editors to be updated to support this feature when Lion is released.
How about a compromise between 1 and 2? Instead of a folder+repo for each script, can you bundle them into loosely related groups, such as "database", "backup", etc. and then make one folder+repo for each group? Then if you clone a repo on another machine, you're only pulling down a smaller number of unrelated files. (Is the bandwidth/drivespace really a concern?) To me, this sounds WAAAY simpler than all of the other suggestions so far.
(Technically this approach meets your requirements because (1) each script isn't in its own directory, (2) not all scripts are in the same repository, and (3) you can easily do this with any popular DVCS. :D)
UPDATE (2016): Apparently, a guy named Cosmin Apreutesei created a tool named multigit, which seems to implement what I wished for in this question! If you ever read it, thanks a lot Cosmin! I've started using your tool this year and find it awesome.
I'm starting to think of some kind of an overlay over Mercurial/git/... which would keep a couple "disabled" repository meta-directories, let's say:
.hg1/
.hg2/
.hg3/
etc., and then on hg commit FILENAME would find the particular .hgN that is linked to FILENAME, and would then temporarily:
mv .hgN .hg
hg commit FILENAME
mv .hg .hgN
The main disadvantage is that it would require me to spend some time writing the tool. Or does anybody know of some ready-made one like this? If you do, please post as a full-featured answer (not a comment), I'm more than willing to accept it.
I have a file that was deleted a few changesets ago. As you can imagine, the other files in my project have changed since then. How can I get back that file (it's actually 2 files) without reverting all the other source files?
Use hg revert for just that file:
hg revert -r REV path/to/deleted/file
From the help for hg revert
If a file has been deleted, it is restored. If the executable mode of a file was changed, it is reset.
If names are given, all files matching the names are reverted. If no arguments are given, no files are reverted.
Another approach to this is to use the Kiln website. You can search for a changeset by changeset id, or just use a date search, .e.g. date:2011-10-01..2011-10-31
That will then give you a list of changesets, click the one that will show the version of the code you want to recover, and then if you click the Browse files at [changeset id] link on the right hand side you will then get a list of the folders and files at that point in time.
You can then just add new files to your project and cut and paste the code back into those new files.
Admittedly this isn't as nice an approach for recovering a whole file, but it's handy if you only want to recover part of the code, or if someone has subsequently added a new file with the name of the old file.
vimdiff helps in showing the diff of two files graphically and allows us to pick the changes from left to right/right to left.
The files I am dealing with are huge files and most of the differences vimdiff reports can be auto-merged except a few.As it takes lot of time to go diff by diff in vimdiff and take the action.
I would like to know if there is an option available in vimdiff that automerges the differences in left and right files as long as there is no ambiguity and leaving the conflicted resolutions similar to the tools svn merge and cvs merge tools does?
Its not possible to auto-merge the changes in two files unless we have a base copy where these two files branched and changes done separately. If an item is on one side and not on the other,it can't judge whether this item was newly added or an existing item was deleted. As there is a base copy exists while merging files in a repository, cvs merge,svn merge can auto-merge the changes.
If you use no version control, you can try diff and patch this way:
Before changing your file (say, file.txt), make a backup of the original version (file.orig).
When changed are made, make a patch-file: diff file.orig file.txt >patch.txt
Get a file which you want to merge changes to (say, file2.txt).
Use patch: patch file2.txt patch.txt
Changes will be merged, conflicted rows will be placed in a separate file.
Looks like vimdiff does not allow that. Man page says
"vimdiff - edit two or three versions of a file with Vim and show differences"
But you can have a look at Kdiff3 which lets you compare and merge.