I am having issues with the command-line client of svn - svn-win32.
Current situation:
We have a directory with multiple subfolders, like so
file1
folder/archives/file2
folder/archives/file3
Situation1:
A new file is added via checkout.
Everything behaves as it should.
Situation2:
An existing file is modified via checkout.
Result: Existing file remains, and is marked as "modified".
Desired result: Existing file fully overwritten, local changes lost.
How do i achieve the desired result?
svn revert -r pathname
svn up
did not help.
svn revert requires a path be passed in; use svn revert -r . to discard all changes in the current directory and everything below, or specify a directory or file if you want to revert that path and everything below it. Then you can run svn update.
Related
Using git init in my terminal on mac creates a hidden a folder. I used command + shift + . to show folder, but it appears faded and can't be detected for further functions.
enter image description here
Code:
cd "desired folder"
git init .
when i cd .git, it works; however, i cannot ls into .git. I can also add and remove in code but the changes appear as changes to be committed. When I open the .git folder my files aren't saved there.
Could someone please assist?
Thanks
Git stores its data within the .git directory, and that directory is created by running git init (or as a part of running git clone). On macOS, like other Unix systems, files that start with a dot are hidden, which is normal, and it's intended that this folder should be that way.
Once you've committed data, that data will be stored in the .git directory in an internal format, so it will not be readily visible. If you want to access it, you'll need to do so using the git command or a library, such as one based on libgit2.
You should, unless you know what you are doing, not modify the contents of the .git folder, possibly with the exception of the files in .git/info and .git/hooks (after reading the documentation thoroughly). Also, the history of your project is stored there, so if you delete the directory or its contents and haven't pushed the changes elsewhere, you'll lose data.
So it appears everything is working as expected in this case and you can just ignore the .git directory and its contents, using the git command as normal.
I'm working on a python project and want to rename a (package) folder to small letters, let's say from Myackage to mypackage. As git is case-sensitive and Windows is not, I followed the solutions taken from here and espacially here.
My procedure was as follows:
git mv Mypackage tmp
git mv tmp mypackage
git commit -m "Change capitalization of package name"
This changes the folder Myackage to mypackage with success (for both, git and Windows). But if I switch to another branch, I expect the folder to change back to Mypackage (with capital letter!), as it was before. Background is, that all the imports of the package are also case-sensitve in python and i need this renamng acompanied with adaptions of the imports.
I've tried both, core.ignorecase set to true and false, but no matter what I try, if I checkout an older branch, the folder remains in form of small letters (mypackage) and I run into issues within python.
UPDATE:
I've set up a small example with only one Folder and one file and could succesfully change the capitalization of the folder. It also shows the desired behaviour, that upon branch switch the capitalization of the folder in Windows changes, yet still this won't work for my python project.
Could it be, that, e.g., submodules, play a role here?
UPDATE 2:
I've checked the case sensitivity attribute for both cases via:
fsutil.exe file queryCaseSensitiveInfo .
Both folders claim, that case-sensitivity is deactivated. Still for one project folder name capitalization changes, but for the other folder not.
The attribute case sensitivity is available on Windows 10 but after April 2018 Update and only affect the specific folder to which you apply it. It isn’t automatically inherited by that folder’s subfolders. However, if you use WSL to create folders it's enabled by default and available in that way to Windows. [1]
Although you can use the Git Unite [2] tool to match the case of the current folders with the git index.
If you use the rename approach, try using it with git commands like in "Rename files and folders with git"[3]
git mv foldername tempname && git mv tempname folderName
I found a way to reproduce your behavior :
if my CaSeD folder contains some extra files (untracked files for example), git will not change the case of my folder name when I jump between commits.
Is this the case in your setup ?
If this is your issue : you could go with a post-checkout hook, which forcibly renames the folders according to what is stored in HEAD after a checkout.
One way to get the full list of paths to directories from commit HEAD is :
git ls-tree --name-only -d -r HEAD
If you match this list with a similar list extracted from your local file system (ls -r ? find . -type d ? some python function from os.* ?), you can spot what folders need to be recapitalized.
We are forced to work on Windows at work, and I have lets say problem, strange situation. We have github repository, inside which we have one directory with name Something (with capitalized first letter 'S'), but in my local I see this directory with name something (note lower case 's'), git status shows that working directory is clean, even if I change this directory locally to, for example SoMeThInG git says that nothing changed. I suspect that Windows is here a problem, as it is case insensitive. Is there possibility to change this directory name from Windows level? Or maybe how to force git bash to be case sensitive?
Update
I've changed that files from mine virtual fedora, but this is just a workaround, the question remains unanswered, how to do it properly on Windows?
On case-insensitive file systems, Git will not detect changes just in casing. However, when committing files, the actual casing is still being reflected in the way it was added to the index.
So a git add file and git add FILE will both work for a file that is named file in any kind of casing (e.g. FiLe or fIlE), but each command will actually stage that exact name into the repository. So git add file will make the name be case-sensitive file and git add FILE will make the name case-sensitive FILE.
That’s why you should try to always use your command line auto completion for file names, so you don’t accidentally add files with a different casing than they actually are. Or use commands that stage the files automatically, e.g. git add ., since that will also use the actual casing.
However, since Git will not detect casing changes, once a file has been added with a particular casing, that casing will be used until you explicitly change it. That’s why it’s possible to have files in a folder src/readme.md and SRC/license.txt that are both physically in the same location on your file system, but are represented using incompatible paths inside of Git. So you should be careful here.
That all being said, you can fix the casing later. But to do that, you need to make the change using Git instead of the file system, as Git is case sensitive while the file system isn’t. So commands like git mv will work. Same as a combination of git rm --cached and git add.
For example, to fix the above situation of the src/SRC directory, one could do (assuming the correct name of the folder should be Src):
git mv src/readme.md Src/readme.md
# or
git rm --cached SRC/license.txt
git add Src/license.txt
You can also fix the casing for every file by removing everything from the index, and then adding it back:
git rm --cached -r .
git add .
That should stage all renames to the correct file casing.
Hi i want to revert all changes to the files with a specific filename in a local repository.
In this case AssemblyInfo.vb, i'm using the TortoiseSVN cli.
I have the following directory structure
Root
Project 1
File1.txt
My Project
AssemblyInfo.vb
Project 2
File2.txt
My Project
AssemblyInfo.vb
Now while standing in Root i run the command svn.exe revert --recursive AssemblyInfo.vb and the output i get is:
Skipped 'AssemblyInfo.vb'
I have tried to add double and single * before the filename with no success, does --recursive/-R work or what am i missing?
svn help revert gives the following output:
revert: Restore pristine working copy state (undo local changes).
usage: revert PATH...
Revert changes in the working copy at or within PATH, and remove
conflict markers as well, if any.
This subcommand does not revert already committed changes.
For information about undoing already committed changes, search
the output of 'svn help merge' for 'undo'.
Valid options:
--targets ARG : pass contents of file ARG as additional args
-R [--recursive] : descend recursively, same as --depth=infinity
--depth ARG : limit operation by depth ARG ('empty', 'files',
'immediates', or 'infinity')
-q [--quiet] : print nothing, or only summary information
--changelist [--cl] ARG : operate only on members of changelist ARG
Global options:
--username ARG : specify a username ARG
--password ARG : specify a password ARG (caution: on many operating
systems, other users will be able to see this)
--no-auth-cache : do not cache authentication tokens
--non-interactive : do no interactive prompting (default is to prompt
only if standard input is a terminal device)
--force-interactive : do interactive prompting even if standard input
is not a terminal device
--trust-server-cert : deprecated; same as
--trust-server-cert-failures=unknown-ca
--trust-server-cert-failures ARG : with --non-interactive, accept SSL server
certificates with failures; ARG is comma-separated
list of 'unknown-ca' (Unknown Authority),
'cn-mismatch' (Hostname mismatch), 'expired'
(Expired certificate), 'not-yet-valid' (Not yet
valid certificate) and 'other' (all other not
separately classified certificate errors).
--config-dir ARG : read user configuration files from directory ARG
--config-option ARG : set user configuration option in the format:
FILE:SECTION:OPTION=[VALUE]
For example:
servers:global:http-library=serf
If i run svn.exe revert --recursive AssemblyInfo.vb in a directory that directly contains a modified AssemblyInfo.vb it works as intended.
svn revert is designed to help fix mistakes, not cause problems by "helping" users to accidentally or unintentionally remove their local and uncommitted changes.
If you want to revert all the changes in your SVN working copy or in a directory and all its childs, you could run svn revert . -R. But you must not run this command if your working copy has a mixture of valid uncommitted changes that you don't want to lose and the changes that you want to revert to unmodified state.
Reverting local changes is an irreversible operation. Therefore, reverting local changes in SVN working copy via svn revert must be done cautiously. Assume that you are working on a task and haven't yet committed some important changes you've been working on a couple of hours. But at the same time you have some changes in a file or directory that you want to revert. Carelessly running svn revert . -R at the root of working copy will revert all the uncommitted changes in the working copy.
Citing SVNBook | svn revert
svn revert is inherently dangerous, since its entire purpose is to
throw away data—namely, your uncommitted changes. Once you've
reverted, Subversion provides no way to get back those uncommitted
changes.
If you provide no targets to svn revert, it will do nothing. To
protect you from accidentally losing changes in your working copy, svn revert requires you to explicitly provide at least one target.
Now while standing in Root i run the command svn.exe revert
--recursive AssemblyInfo.vb and the output i get is:
svn revert does not work this way. By default, it runs with --depth=empty to ensure that it won't revert more than the user intended. But runningsvn revert with -R is the same as running it with --depth=infinity. Generally speaking, in this particular case --recursive is an alias for --depth=infinity and its purpose is to help users revert all the local modifications (e.g. after invalid merge).
When you run svn revert with --recursive, the tool expects you to specify a path to a directory in your working copy and the operation will revert ALL the changes that are in this directory and its childs. There will be no effect if the command's target is a file.
What you look for is --targets and a bit of scripting. For example, run the following commands in PowerShell console (I'm sure that it could be done more elegantly in PowerShell than in this example):
(dir -Path "files.html" -Recurse -File).FullName | Out-File -Encoding ASCII mytargets.txt
svn revert --targets mytargets.txt
dir is an alias of Get-ChildItem cmdlet in PowerShell. In this case it grabs the list of all files with name files.html and writes the full paths to mytargets.txt file. Then it runs svn revert that reads paths from mytargets.txt and revert local modifications made to the files.
I advise this approach instead of piping the output to svn revert because you can (and should) review the list of items that svn revert will process. This helps you ensure that you won't revert more that you actually intended.
On Linux this can be done using combination of find and xargs commands from findutils:
find -name AssemblyInfo.vb | xargs svn revert
On Windows you can probably install and use Cygwin which contain these utilities.
I have an XML file that we consider binary in git. This file is externally modified and committed.
I don't care about who edited it and what's new in the file. I just want to have the latest file version at every pull. At this time, at every git pull I have a merge conflict.
I just want that this file is overwritten on every git pull, without manually doing stuff like git fetch/checkout/reset every time I have to sync my repo.
Careful: I want to overwrite just that file, not every file.
Thanks
I thought you could use Git Hooks, but I don't see one running before a pull...
A possible workaround would be to make a script to delete this file and chain with the needed git pull...
This answer shows how to always select the local version for conflicted merges on a specific file. However, midway through the answer, the author describes also how to always use the remote version.
Essentially, you have to use git attributes to specify a specific merge driver for that specific file, with:
echo binaryfile.xml merge=keepTheirs > dir/with/binary/file/.gitattributes
git config merge.keepTheirs.name "always keep their file during merge"
git config merge.keepTheirs.driver "keepTheirs.sh %O %A %B"
git add -A
git commit -m "commit file for git attributes"
and then create keepTheirs.sh in your $PATH:
cp -f "$3" "$2"
exit 0
Please refer to that answer for a detailed explanation.
If the changes to your files are not actual changes, you should not submit them. This will clutter your version history and cause numerous problems.
From your statement I’m not quite sure which is the case, but there are 2 possibilities:
The file in question is a local storage file, the contents of which are not relevant for your actual sourcecode. In this case the file should be part of your .gitignore.
This file is actually part of your source and will thus have relevant changes in the future. By setting up the merge settings like you are planning to do, you will cause trouble once this file actually changes. Because merges will then be destructive.
In this case the solution is a little bit more complicated (apart from getting a fix for the crappy tool that changes stuff it doesn’t actually change …). What you are probably looking for is the assume unchanged functionality of git. You can access it with this command:
git update-index --assume-unchanged <file>
git docu (git help update-index):
You can set "assume unchanged" bit to
paths you have not changed to cause git not to do this check. Note that setting this bit on a path does not mean git will check the
contents of the file to see if it has changed — it makes git to omit any checking and assume it has not changed. When you make changes
to working tree files, you have to explicitly tell git about it by dropping "assume unchanged" bit, either before or after you modify
them.