If your repository has a few paths that are synced by the repo tool using a manifest-file/group/branch & you run the repo commands (init->sync->checkout) again in the same repository but with some other manifest-file/group/branch having a different set of project paths then the current execution of the repo command will remove/delete the unnecessary project paths.
At least, what I expected from the repo tool was that the project paths which were not relevant to the current execution to be kept as is.
But, instead, you'll see a sequence of log lines saying the obsolete paths have been deleted as they were not necessary.
Deleting obsolete path /path/to/other/project1
Deleting obsolete path /path/to/other/project2
Deleting obsolete path /path/to/other/project3
Deleting obsolete path /path/to/other/project4
Repo tool has this by design.
I looked at multiple problems over the internet for solutions but couldn't find any.
Finally, I could design my own WAR.
Internally, the repo tool decides which paths to keep & which to delete in 2 ways.
If the paths to be deleted has some changes then it ignores deleting them.
By comparing the project.list file in the .repo folder & only keeps the ones listed in it.
Method 1 wasn't much useful for me as before the checkout I happen to reset the entire working tree.
On the other hand, Method 2 was what I needed.
WAR
Update the project.list file in .repo folder of the repository to remove the paths that you think the repo tool should not delete.
Let's say I don't want repo tool to mess up my path "/path/to/other/project3" then I would remove this line from project.list file.
Related
I've encountered a problem long time ago which I couldn't solve, but I'm curious whether it's possible to fulfill ALL of the below listed criteria at once or not.
The solution what I was looking for can:
somehow refer to an existing file or folder from another folder of the same git repo
basically reach the content of the file or folder from another subfolder, see the content(s) as if they were on the another path as well
e.g.: if ./path/to/folder is referred from ./another_path/different_folder, then every file in ./path/to/folder/* is visible on path ./another_path/different_folder/*
e.g.: if ./path/to/file is referred by ./another_path/different_file, then by reading/writing content of the different_file, the original file is read/modified
store the referred file only once in git repo
don't want to make a copy of the file to another path and maintain changes in both files simultaneously
be able to use multiple references for a single file
be able to use relative paths
make it work on both Windows and Linux
As if I can remember, some of the problems were while experimenting with this:
the paths were broken after the repository was pulled to a different path (I assume they were not relative, but absolute)
the Windows style links are special files, were not working on Linux
the symlinks can't handle relative paths correctly on the Windows system
the hardlinks resulted duplicating files in Windows
(I can't remember exactly which if these might be incorrect, but I'll experiment with the problem again and try to update this question.)
Is there any workaround for this problem?
Thank you for any help!
Please note (in case you would like to mark this question as a duplicate), that there are other similar questions here, but none of those questions define this set of the criteria, therefore it can't be a duplicate.
I'm using TortoiseSVN on Windows 10 for my SVN repository. I have now changed some files and folders.
How can I set them to ignore, so that the files/folders are not removed (or changed) from the repository, but just no commit of them takes place?
All appraoches I have seen so far remove the files from the repository.
In TortoiseSVN Settings on the General page (the first page that opens up), there's a Global ignore pattern option that allows you it ignore certain folders or extensions:
If you want to ignore a specific file (or folder), right click the file, click TortoiseSVN, and click Add to Ignore List. You'll get options to ignore the file, any file with the file's extension, and a few others. This property is committed to the repo for the folder.
Note: This option is only available if the file has not already been added to the repo.
If the file has already been added to the repo, there's no option to ignore changes. See Ignore files which are already versioned
You may also want to check out Subversion: ignore modifications to a file locally on one client only. If this solves your problem, you may want to delete this question as a duplicate.
At some point during my adventures with Linux, I decided that it would be a good idea to put everything in my home directory into source control. I'm not asking whether that was a good idea or not -- I'm asking how to undo it.
The reason for removing the repository is that I recently installed Oh My Zsh, and I really like it. The rub is that my home directory has a big git:(master) stuck behind it, and I'm just not a huge fan of that.
So what I would like to do is remove the git repository itself, so that the git:(master) is no longer displayed, without deleting all of my files.
Just remove (or rename) the .git subdirectory. That subdirectory is the whole of the repository. This will not delete your files, but it will delete their history.
Additionally, there might be files like .gitignore and .gitattributes that are not necessary anymore.
Make sure that all your files are present in the working tree before removing/renaming .git.
Your repository resides in the .git directory, you can delete it easily. But if only the prompt disturbs you, it is enough to search where PROMPT gets new value in your environment and modify it to something else.
Removing the directory .git in a repository removes the history, and keeps the files currently checked out - it does not keep all files.
Warning: this may not be what you need!
The history contains earlier states of files, files that were removed at some time, and other branches, containing similar, up to date files similar to the currently checked out, or completely different ones.
That means, in the general case, removing the .git affects files that where in the repository tree earlier, and files that currently - in the newest version - exist in other branches. All these would be deleted too!
The answers proposing to just delete .git apply only in the simplest case,
where you only added files to the master branch since creating the repository, and master is checked out.
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 have a settings file that is under version control using subversion. Everybody has their own copy of this file, and I need this not to be ever committed. However, like I said, there is already a copy under version control. My question is: how do I remove this file from version control without deleting everyone's file, then add it to the ignore list so it won't be committed? I'm using linux command line svn.
Make a clean checkout, svn delete the file and add the ignore. Then commit this. Everyone else will have to take care (once) that their local copy isn't deleted on the next svn update, but after that, the local file would stay undisturbed and ignored by SVN.
If you remove the file from version control, how does a developer new to the project (or the one who accidentally deleted his local copy) get it after initial checkout? What if there are additions to the settings file?
I would suggest the following: Keep a default settings file (with no passwords, hostnames, connection strings, etc.) in SVN, name it something like settings.dist, and let the code work with a copy of this, named settings. Every developer has to make this copy once, and can then work with her personalized settings. If there are additions, add them to settings.dist – everyone else will get them with a update and can merge then into her personalized copy.
After you delete the file, your users will have to recover the file from the repository using svn export.
$ svn export -r x path ./
Where x is a revision where the file existed before it was deleted, path is the full path to the file, and ./ is where the file will be placed.
See svn help export for more information.
simply define a file containing settings that will override the default ones. This file is not checked into Subversion and each developer is responsible for maintaining this file according to their environments.
In an Ant-based world, you would have the files:
settings.properties
settings-local.properties (ignored for Subversion)
and in your build.xml file
<property file="settings-local.properties"/>
<property file="settings.properties"/>
For those who couldn't connect the dots:
modify the build.xml file like proposed
set the setting-local.properties as ignored
in an init target of your build, copy the settings.properties to settings-local.properties
wait a couple of days until everyone had the chance to run this target
delete the setting.properties from Subversion
Voila, every developer has its own setting-local.properties and everything was done automatically (and no developer lost his or her settings, which happens if you brutally delete the file from Suvbersion and there is no "Everyone else will have to take care...")
I have a similar issue. In my case it's an auto-generated user settings file (visual studio) that was accidentally checked in very early in the project. While just deleting it might work, it seems more correct to have it removed from the history, as it was never supposed to be in there in the first place.
I came across this, which might be a new feature since this question was originally posted 7.5 years ago:
https://stackoverflow.com/a/6025750/779130
Seems like an idea would be to:
1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.
This might be the only way to completely get rid of the file. In most cases the "delete and ignore" approach might be good enough.
[[ I'm new to subversion, so maybe this doesn't make sense. marking this as wiki -- if you know the right answer, please APPEND in the later section ]]
Couldn't you have a custom set of checkout steps so each user gets a different settings folder?
$ svn checkout http://example.com/project project
..
$ dir project
original_settings\ folder1\ folder2\
$ svn checkout http://example.com/project/aaron_settings project\settings
..
$ dir project
original_settings\ folder1\ folder2\ settings\
Or for new users
$ svn import project\settings http://example.com/project/aaron_settings
What I'm getting at is you want each user to have a custom view of the repository. In other version control systems, you could set up a custom listing of which projects you were using and which you weren't and which you put in odd places.
Does this work in subversion? The above code looks really risky, but maybe i'm doing it wrong.
WIKI:
(nothing yet)