SVN doesnt commit a library like MySql connector, so when I commit my project it is not uploaded to the server, how can I do this, I how to sync another resources like pictures?
SVN, just like any other source control management system, can handle binary files as well. This should not pose a problem.
Check that the file is not under .svn-ignore or any similar ignore flag. Check that any other SVN properties that define the file are set correctly.
Subversion can support any type of file, what software are you using to make your commits? If you are using TortoiseSVN: make sure you have the "Show un-versioned files" box checked and that each file you want to commit is selected.
Bear in mind SVN only commits files marked as added to the project.
I believe you must´ve forgotten to add your file to the repository or, as Yuval A said, maybe it´s on the ignore list.
Related
The IntelliJ 2017.2 documentation suggests including the .idea folder that contains that IDE’s own configuration files (excepting the workspace.xml and tasks.xml files). I can understand the sense in this, as I could incorrectly configure the project settings and want to revert.
Yet, I want to post this open-source multi-module Maven-driven project to BitBucket for public access. Obviously, not everybody uses IntelliJ as their IDE, so I do not want to force my IDE settings on them.
➠ How do open-source authors resolve this conundrum?
My suggestion that comes from experience is to always explicitly ignore (that is, add to .hgignore or .gitignore) IDE configuration files or directories.
It is not only a question of not spamming a project with configuration files for a specific IDE. The real problem begins when more that one person uses the same IDE. Depending on the IDE and on how it is configured, you can fall in a situation where each commit contains changes to these files, and will confuse all the other developer using the same IDE, which in turn will overwrite the changes again in a infinite loop.
Some of your IDE settings will be global and stored in your home directory. The ones that are project specific will survive as long as you don't change the local directory in which you cloned the repo. If you change directory, in my experience it is always tolerable to reconfigure the IDE. There are at least two situations when the local directory changes: (1) you remove the directory and clone the repository again (2) you use more than one computer.
If you are concerned for things like coding style, then the best approach is to use a command-line formatter tool that works for any editor or IDE. That tool will have its configuration file committed in the repo, since coding style is something that should be equal for all developers and files of a repo.
I want to commit only a .java file to an already existing repository. I am using github for a class, and we are each given access to a private repo containing project information. I am supposed to add only a .java file to this repo, but I can't figure out how to do this. I have come close: I committed only the .java file, but it is inside a directory with the same name as my eclipse project.
Is there a way to commit only the .java file, without any of the project information, while keeping the project usable?
Thanks.
edit:
My goal is to have \git\repoName\MyFileName.java
as well as keeping the files already in \repoName\ and keeping the MyFileName.java in a usable eclipse project.
Is there a way to commit only the .java file, without any of the project information, while keeping the project usable?
yes, you will need to create a .gitignore file, and put the rest of your project into the gitignore file, (and also gitignore itself), that way, the only files that are tracked by git are the .java files.
As for the files being inside the directory with the same name as your project, take a look at where you cloned the git repo to, and make sure it is on the same level as your project files.
Take a look at this documentation
http://git-scm.com/docs/gitignore
https://help.github.com/articles/ignoring-files/
I think its much simpler than what you are expecting :)
You can do, git add, docs:
git add yourFileName.java
Now you can commit the .java file
git commit -m "I am updating only .java"
You can either reset or let it be as it is!!
git reset
reset will not have any history. So, be careful if you want to reset. In this scenario I think you dont have to reset. See here for some help.
See my answer on how to push/pull changes from eclipse into github. Let me know for any help on how to interact with github on eclipse.
You want to remove a subtree and create a new repo?
This is definnitely possible but you have to be careful. Creating a subtree only for file like yourFileName.java surprizes me a bit, but why?
For whatever reasons, see this for an easy way, and the original post is this Detach (move) subdirectory into separate Git repository
This blog might also help you.
I figured it out!!
The key was to add a source. You can do it when you create a project, one of the options will say "Link Source" or something along those lines.
You can also do it after a project is created:
Right click the project in Project Explorer. Go to Properties -> Java Build Path (on the left) -> Source (the first tab) -> "Link Source..."(button on the right)
Then just browse for the git repo folder that you already have and you're good to go! Just create new class files within /repoName in Project Explorer.
If anyone needs clarification or anything, let me know.
I am trying a sample project to rename a file using Eclipse. First, I did a commit and pushed to GitHub. The file was Samplemain.java. If I rename that file to SampleMain.java and if I try to commit the renamed file using TortoiseGit, I'm unable to commit. Instead, it's showing an error with a small dialog.
Please let me know the solutions for renaming files with case-sensitive in Git.
I am using Windows, the error dialog is shown below.
This is a problem with TortoiseGit, not with Git itself. If you commit using the command line it will work, I checked it now. Note that renaming still takes 2 git mv commands, but only one git commit, as it should.
Another alternative is to rename the file on GitHub: when editing a file on GitHub notice at the top that you can change the name. After that you can pull from it.
Run following command in Windows command line (MINGW console). It should fix the case detection problem.
git config core.ignorecase false
Two-stage rename... name it to something like 'z.tmp' then back to the name your really want.
I know with Subversion I have to commit between two-step renames, but with Mercurial I don't.
Not sure if Git needs it or not.
There's a utility made for this apparently: https://github.com/tawman/git-unite
I haven't been able to try it myself yet, as the author doesn't provide the final exe files, and I had an issue when trying to run the build script. But it seems to be a utility that would solve this issue more easily.
It searches for name-casing mismatches between repo and folders, and updates the repo to match the folder, letting you then commit with only one version of the files. So just change the names in Windows explorer to what you want, then run the utility, I believe. (maybe followed by a commit -- not sure)
At work yesterday I committed an Java Applet Jar file to our svn project. The project manager pushed it out for me, but when it's on production the file fails. I can open the jar and the classes look fine.
Could SVN be doing this? I don't use svn, I'm just trying to figure out why it works on my dev, but comes out corrupted on production? Maybe a text/binary setting or something?
You really shouldn't be storing binaries (e.g. JARs) in Subversion. Use an artifact management tool such as Artifactory, Nexus or Archiva. You can access the artifacts via Maven, Ant/Ivy, or a variety of other tools. Releases (e.g. WARs) are just URLs given to your release manager.
SVN can corrupt a binary if incorrectly set to text, but that's unusual. I believe *.jar would default to binary, not text, unless someone is doing things by hand incorrectly.
I usually verify JAR/WAR files are ok by just copying, changing the extension to .zip, and opening them up.
I have been using svn for storing jar files for many years and deploy to production right from my svn checkout and have never had an issue.
Try to check md5 of your local copy + on production
openssl dgst /path/to/your/file
Or you have some issue with privileges? Try to omit SVN in order to deploy on production and then check whether everything is OK.
I would very much doubt it.
Have you looked at the comparative filesizes etc ensure all the file has been transferred
While SVN will not corrupt your files by design, it is not totally unthinkable that something goes wrong along the way and you end up with corrupted files.
So in general, when you encounter corrupted files you are affected by either
unexpected effects of data thanges that SVN performs by design (e.g. svn:eol-style keywords)
faulty hardware (bad harddisk?)
bugs in the operating system or its file system; see for example this description of afile corruption bug in Windows 7.
what I'd like to do is have files in a central location so that when I add people to my development team they can see the base version of these files but meanwhile have the ability for the rest of the team to work with their own local version.
I know I can just put the files in source-control (we use Tortoiese-SVN) and have my team change the local versions but I'd rather not as the exclamation mark signaling the file has been changed and needs to be committed, quite frankly, irritates me greatly.
I'll give two examples of what I mean:
We use quite a few build.xml files which relate to a single properties files which contains many definitions. Some of them can be different between team-members (mainly temporary working directories) and I'd like a new team-member to have the ability to get the properties file with the base config but change it if they wish.
Have the eclipse settings file in the SVN so that when a new team-member joins they can just retrieve the files from the server and have a base system running. If they wish they will be able to change some of these settings.
Thanks,
Ittai
What I have done in the past is having the file in a different location or with a different name inside the repository with an ignore real_file rule so that the subversion will not complain on the changed file, and have a small script that will copy the files to the concrete location.
For example, the .project Eclipse project file can be named eclipse-project-default in the repository. When a user downloads the local copy they run the script and they get a fresh .project (copy of eclipse-project-default) that they can change and will not show in the subversion status command.
The problem with this approach is that it is often easy to make a change to the file that should go to the central repository and is forgotten. The approach requires changing the actual file, and applying the same change to the config file that is actually uploaded. And then commit that change.
This really is a case for version control as you point out, but having said that I guess you could put a copy in a central file server and have them download it from their. You may even want to make this a read only file or directory.
If the status indicator bugs you that much you can set this file to be ignored by your version control system.