To keep it simple I will use a simplistic example.
I have a versioned folder A and there are two more folders X and Y and a file f. X and Y may contain any number and depth of files and folders. So the tree looks like this:
A
|-X
| |-[...]
|
|-Y
| |-[...]
|
|-f
Now I have A with all contents fully recursively checked out on my disk.
After a while it shows that I don't need Y any more and I want to delete it from my disk and TortoiseSVN to no longer check it out again or update it. I just need A and f.
But Y should reseide in the repo as usual, unaffected by my local decision.
So how do I accomplish that by means of TortoiseSVN?
If I just delete the folder Y then TortoiseSVN will show me in the commit-box on next occasion that Y is mission and wants me to commit this, which will lead to Y being deleted in the repo as well.
I don't think there's a way to ignore a whole part of a directory tree like that in TortoiseSVN. I think the simplest solution would just be to only check out the parts of the repository that you need, i.e. instead of checking out from the root (A), check out X instead into its own folder.
Related
I have multiple directories/files all over disc, which are logically bounded and I would like them in one git repository. Sadly I cannot move them to one common directory, as different 3.party program looks for them in their respective locations and sometime changes them. Which I would like to track/version.
I also have other git repositories here and there all over disc.
I would like to put in one repository something like
/etc/conf.d/myprog.*
/usr/bin/myprog.sh
/home/myname/somedir/myprog/*
/home/myname/otherdir/myprog/*
while NOT HAVE in there all other directories (so put .git and long .gitignore in / would not be a good idea)
Some could be done with symlinks on place of original files, but there are more *-like expressions, where I cannot force other programs from creating/deleting files there, so symlinks do not help
One possible way is to create some separete git dir and scripts to copy everything there (and delete no longer existing files) before commit and copy (and delete) from there after each checkout, but it is not elegant, the data are huge/many and it means duplicity with all its problems.
Is there more elegant way?
(something like make dirs for each area with .gitignore inside it and something like .git_real_path file containing the real path on the disc, where tis should be applied)
I've imported a project into a directory and the original directory structure is:
//depot/a/b/foo.txt
//depot/a/b/bar.txt
//depot/a/b/c/baz.txt
//depot/a/b/c/boz.txt
Note that none of the files in //depot/a/b have name conflicts with files in //depot/a/b/c.
I'd now like to reorganize things such that all of those text files reside under //depot/newdir/. I attempted this by creating the following branch spec with view lines similar to the following:
//depot/a/b/... //depot/newdir/...
//depot/a/b/c/... //depot/newdir/...
This didn't work. When I integrate, the files in //depot/a/b/c clobber those in //depot/a/b. If I reverse the lines the files in //depot/a/b clobber those in //depot/a/b/c.
I've tried various wildcards (such as the following) hoping to be more specific, and can't get this to work.
//depot/a/b/%%1.txt //depot/newdir/%%1.txt
//depot/a/b/c/%%1.txt //depot/newdir/%%1.txt
Is it possible to migrate all of the files as described above to the //depot/newdir area in a single branch spec?
You should be able to use the move command here.
p4 move //depot/a/b/* //depot/newdir/*
p4 move //depot/a/b/c/* //depot/newdir/*
Those two commands will move all the files in b and c (but not any files in their subdirectories) to newdir.
I am working on a shared project which is put in SVN. The directory structure of the project is as follows:
ParentDir
- Child_Dir_1
+ GrandChild_Dir_1
+ GrandChild_Dir_2
- Child_Dir_2
Child_Dir_1 contains configuration files (Eclipse's .LAUNCH files), and people put all sorts of file in this folder.
So each time I update my source code (by right clicking on ParentDir and picking Update), I got a lot of configurations that I don't really need, and I have to delete them manually.
I still need to have the children of Child_Dir_1 (which are GrandChild_Dir_1 and GrandChild_Dir_2) to be updated.
I have tried to go to set the "ignore" property of the of Child_Dir_1 to exclude *.LAUNCH files, but each time I update the source code, the ones that I manually deleted are restored to Child_Dir_1.
Since you are using TortoiseSVN:
Go into Child_Dir_1, select GrandChild_Dir_1 and GrandChild_Dir_2 and right click, TortoiseSVN -> Update.
That will update only those two folders.
Ignore is so that you can "ignore" ( from commit, status etc.) untracked files, files that are not checked in.
It could be that manojlds' answer is the solution for you, but I have doubts. The problem here is that those files are really part of the project. They are kind of unavoidable, and must be in sync with the rest of working copy.
Option 1 (best): Remove all configuration files form repository, or better yet have in repository only configuration template files (with, say, $ as first character in file names). Each user could copy those template files to true configuration files and change them accordingly. Configuration files should not ever be committed. Only template files should, but updating template files will not mess with current configuration files of any user.
Option 2 (second best): Ignore those configuration files. Use your own files for your own configuration, with names that don't clash with existing. You may even add your files to SVN, but you may just as well not add them. Does not matter, as long as you don't need your configuration on another machine.
Option 3: Use ignore-on-commit group. Use those configuration files that already exist. Change them to your likings, but don't ever commit them. To ensure that you don't commit them by accident flag them as non-committable (go to commit window, select all non-committable files, right click > Move to changelist > ignore-on-commit). The problem with this is your files are not protected from other users' updates, but may actually be a good thing.
Option 4: Chop the folder out (a horrible hack). Remove Child_Dir_1 from working copy (Right click on it > Update to revision > set Working depth to Exclude). Save the folder elsewhere first, because it will disappear. After that create it again, inside it checkout all subfolders (GrandChild_Dir_1 and GrandChild_Dir_2), and copy your configuration files. Now you have complete control over folder's contents, but update and commit become more complicated.
Edit: There is option 5 in theory, but I doubt it can be implemented successfully. You can try: Use NTFS hard links. Copy the whole tree with all files as hard links to existing files, except .svn folders and their contents. Original directory is used for SVN operations update, commit, add and delete, and new directory is used for editing files. From new directory delete all the files you don't need, and insert all the files you do need that are not the part of SVN. The problem here is minor extra work when deleting files from and adding them to SVN.
I've been using Tortoise SVN + Visual SVN for about a year since left the corporate world to do my own startup. There's one feature in Tortoise SVN that I've never figured out:
How can I bundle up a bunch of changes into a PATCH or DIFF file and either: A) share them with my co-founder; or B) archive them into a standalone change that I can either "apply" or "revert" on my dev box?
At my previous employer, we used an internal tool that let us build so-called DPK files that contained a set of local changes. You could add changed files to the DPK and then share it with colleagues. They could either review the changes in a Diff tool or apply all the changes from the DPK to test your change on their box. After the review was complete, you could then check in these changes. You could also have multiple DPK's applied at the same time (provided you didn't have overlapping changes).
I want to achieve the same thing with Tortoise SVN + Visual SVN in the VS2010 IDE.
My real-world scenario is that I have some extensive change pending but uncompleted on my box. I want to ZIP up these changes and store them in a DIFF file, revert the changes, move on to something else, work on that, and in a few days reapply my changes from the archived DIFF file.
Reluctantly answering my own question. This feature is available with Tortoise SVN. Basically, you make a PATCH file, distribute it or archive it, and then you apply the PATCH. The only trick is to make sure you're in the right location in the WC (Working Copy) when you do the "apply". When you apply, you'll get a popup menu to the left with a list of all files in the changelist. You can apply the patches one by one or in bulk. Seems to work great. I should have drilled into the docs more before posting this question.
Here's the text for picking the location:
"Patch files are applied to your
working copy. This should be done from
the same folder level as was used to
create the patch. If you are not sure
what this is, just look at the first
line of the patch file. For example,
if the first file being worked on was
doc/source/english/chapter1.xml and
the first line in the patch file is
Index: english/chapter1.xml then you
need to apply the patch to the
doc/source/ folder. However, provided
you are in the correct working copy,
if you pick the wrong folder level,
TortoiseSVN will notice and suggest
the correct level."
Be sure to pick the location carefully. If Tortoise SVN can't find it because you selected the wrong node in the VS file explorer, it will try to find a matching location and that might be wrong. In my tests, the Patch feature actually tried to map to a branch (!!) when I specified the wrong location.
Here's the relevant link:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html
I have a project with some part of the code that are public and other that are not.
I have the complete project versioned in my entreprise in folder E, and a specific folder P where I put the public part.
I thought it was a good idea to put hard-links in folder P of the public files in the folder E.
So that, the usual workflow should be to work on the enterprise versioned folder E, and once in a while go to folder P to commit the public files. (note that if I work 'alone', it works great)
The problem is that when I do some merging/pulling/rebasing of the files in folder E, it replaces the files -> thus changing their inode -> thus the files hard-linked in folder P do not get updated!
So my question is:
is there a version control system which authorizes an option not to change inode of files when merging/pulling/rebasing?
I work with git (or git-svn), but I would agree to switch for this convenient option.
Thanks
Louis
PS: I've seen this question (Git and hard links), but here I would like to take advantages of hard links to work more efficiently.
My suggestion is to use symlinks; they don't depend upon the inode, and I know they can be versioned in Subversion (and I would expect git). Versioning hardlinks would be very difficult, since it's plausible - albeit a very bad idea - that part of your working copy could cross filesystem boundaries.