OK, I admit that I must have screwed up when I started using EGit. I started using Eclipse Galileo as a welcome alternative to Notepad edit and command-line compilation. Somewhat later I discovered that Git was integrated into Eclipse, and happily started using it.
I do not remember all the details, but it seems that I made an initial mistake that has been carried on from one computer to another and one Eclipse upgrade to another.
I have consistently tried to specify that source files are in project subdirectory src and their products are in project subdirectory bin. Git wants to archive anything in bin, as well as project metadata at the same directory level.
In the past I have been so mono-focused on the project that I just sprinkled gitignore files everywhere and clicked on "Ignore" when preparing a commit. But now that the project has been brought to a dead halt due to problems in Eclipse Kepler I have resolved to try to disentangle the mess while upgrading to Eclipse Luna.
As I see it, there are three alternatives: (1) Figure out a way to separate the various directories, (2) Brute force copy-and-paste the 300 some-odd source files into a new, clean directory structure (complicated by the fact that there are currently four open Git branches and several uncommitted changes) or (3) copy the current mess and continue to deal with extraneous "changed" files.
Alternative number one is of course the most desired.
Any suggestions?
(Later)
Please be patient with me. I am a newby in this venue. But quite experienced in other venues, where I learned to search for similar questions before posting.
I did try to search for similar problems, to no avail. I also noticed that, while composing my question, there appeared a list of other questions that might be related. None seemed applicable, so I ignored it. When I came back to see if there were any answers, there was the list again and this time I found Eclipse + EGit: clone project into workspace. Perhaps it was there at the top of the list when I finished composing. I'll know to look next time.
I tried the first recommendation, cloning via EGit from the current location to a new one. It seemed to work okay, but there are a couple of things missing: Only the specified branch is available (not MASTER) and the extensive history for the last three years is reduced to one entry dated at the time of cloning.
Fortunately, the other three branches (including MASTER) are not currently divergent. If necessary, I can manually create them again - if there is some way to recover or display the complete history in the clone.
I was not surprised to see that the several unstaged changes in the source were not present. I can deal with those manually, but I wonder if it would help if I staged them before my next attempt to clone?
(Staging those changes may or may not be possible. I became very frustrated with problems using Eclipse Kepler and gave up trying to do anything more to resolve the problems several months ago. I did not document the problems, and by now have forgotten what they were. I have a vague memory of trying to commit current changes and running into fatal errors.)
Now I think I have a more focused question - or rather several questions:
(1) When upgrading Eclipse to a new version, is EGit cloning the easiest way to continue an existing project on the same disk? Should I just copy the original directory? Should I first clone to GitHub and then clone back to the disk from there?
(2) Should I attempt to stage the uncommitted changes before cloning?
(3) Why is Git history reduced to one entry? Would it help if I let MASTER be the default branch and then what? Check out the current (rather lengthy) branch? Or something else?
(4) What should I do about .project, .settings and other configuration files? Is it okay to copy them into the new directory structure in the desired places? Or should I make note of all settings and reconstruct them in Eclipse Luna?
Assume there are two PC PC_A and PC_B and a cvs repository.
PC_A and PC_B have the same code as in repo.
Now I wrote some code on PC_A and check in ,then I cvs diff on PC_B ,it says no difference and the code is old.But it will change when I do cvs udpate?
My question is why cvs update exist and what really cvs update do ?
Yes, it will attempt to update your working directory. If you don't want that, create a branch.
Cvs diff will compare your code against the version you currently have checked out. (Ie, cvs diff does not show you what the differences are to what PC_A just checked in, it will only show you what files you have changed locally but not yet checked in.
cvs update will update both your local copy and the 'version' to give you any new checked in changes. ie, what PC_A just did. If the file hasn't been modified locally, it will update it. If it has been modified, it will attempt to "merge" the two files together, but if it can't then it will say that the file is conflicting and you have to do it manually.
I know that you can track changes to renamed files from a repo to it's clone. However, I seem to have an issue when I rename a file to a file name that is already being tracked. In essence, I want to copy over a tracked file.
Files in original repo:
application.txt
special.txt
Then clone the repo, delete application.txt and rename special.txt to be application.txt
I would expect that the next time I made changes to special.txt in the original repo, the changes would carry over to application.txt. However, it doesn't. I get this message
local changed special.txt which remote deleted
use (c)hanged version or (d)eleted?
Trying this same thing out in Git seems to have the same results. Renaming a file to a brand new name has no issues while trying to rename a file that has already been 'taken' causes conflicts. Is there any way around this?
I wouldn't really call this a bug, as you have for all purposes just changed the contents of a file that mercurial is already tracking. Mercurial tracks files by file name and extension, and you could make the case that this is no different than just replacing the entire contents of the file.
I just had this problem in a real world project with Mercurial. GIT is also seeing bogus conflicts (special.txt deleted and updated).
Bazaar has proper rename support and it merges this case correctly (changes to special.txt are carried over and application.txt get updated as expected).
The problem with Bazaar though (at least for me) is that it lacks IntelliJ support. There are 2 plugins, the most recent has not been updated for 3 years, and last time i tried it was unusable with recent IntelliJ versions.
Since "bzr mv" and "bzr rename" need to be invoked by the IDE at the time of refactoring, the lack of support makes Bazaar unusable for me.
If you want IntelliJ support for this, vote here: http://youtrack.jetbrains.com/issue/IDEABKL-5344
[answer auto-selected by bounty system against my will]
I'm using subclipse, and always when delete a folder in Eclipse, and try to commit it, the following errors raise:
svn: Item <folder> is out of date
svn: DELETE of <folder>: 409 Conflict (http://myintranet)
Deleting and commiting via command line works fine, but what's wrong with doing it via subclipse? Is anyone more experiencing this problem?
(I experienced this problem in Ubuntu 9.10 and 10.04; last Eclipse version; and subclipse 1.4 - as the next versions of subclipse have much more bugs)
--updated: Its when I delete folders, not files
Isn't that addressed by the Subclipse FAQ?
Whenever you see "out of date" in an error message it means that the revision of the item in the repository is newer than the copy in your local working copy.
The solution is always going to be to run an update, so that your working copy is up to date with the repository, and then do the commit again (assuming that the update did not generate any conflicts).
For files, this is usually pretty easy to understand how and why this happens.
However, Subversion also versions folders, and it is usually with folders that this problem most often happens.
Subversion does not allow you to delete/rename a folder OR change its versioned properties, UNLESS the local copy of the folder is at the HEAD revision of the folder in the repository.
Your next question might be:
"OK, I can maybe understand that, but why is my folder out of date? I am the only person working in this repository."
That is a valid question, the answer lies in the way that Subversion works.
When you commit a change to a file, the revision of the file in your working copy is updated to that new revision when the commit completes, however the version of the parent folder(s) of that file is not updated.
This is because there may have been adds/deletes to other files in that folder and until you have run an update, the folder is not really at that new revision.
This is called "mixed revision working copies".
In summary, the answer is always to do an update so that the folder or file is updated to its HEAD revision.
About "Mixed Revision Working Copies":
One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers.
One of the fundamental rules of Subversion is that a “push” action does not cause a “pull,” nor vice versa.
Just because you're ready to submit new changes to the repository doesn't mean you're ready to receive changes from other people.
The fact is, every time you run svn commit your working copy ends up with some mixture of revisions.
The things you just committed are marked as having larger working revisions than everything else. After several commits (with no updates in between), your working copy will contain a whole mixture of revisions
(and that is why, I believe, you cannot reproduce your "out of date" message on subsequent commits with folder deleted: your update did solve the "mixed revision" state.)
Mixed revisions have limitations
You cannot commit the deletion of a file or directory that isn't fully up to date.
If a newer version of the item exists in the repository, your attempt to delete will be rejected to prevent you from accidentally destroying changes you've not yet seen.
i think if you UPDATE before that it should work.. it did work for me
There's a simple solution without installing some extra software. I also had this "problem" and what you can do is the following:
1) open the SVN Repository view
2) there go to the folder you want to get rid of and delete it
3) go back to the java view
4) update the folder in your project you actually deleted / update your project should also work
That solved the problem in my case, as updating only retrieved the files I deleted
Subclipse has many problems like this. It works 90% of time, and then it just DOES NOT work as it should! I am using subclipse, since it is very well integrated into eclipse, and when I have problem or some bigger moves needed in svn (like merging some branch) I use Tortoisse.
I had the thing with directory like you. Then I just run the TortoiseSVN like #luiscolorado suggests, and it helped. Tortoise is so great tool (it has many great features for diffing, applying patches, getting patches and so on.).
Today I had a problem when I have removed a file, and someone had changed the same file! Then subclipse shows conflict (up to this point everything is ok), so I wanted to revert! But then the revert button is missing (disappears when inconflict mode!) so I have to do merge, and merge does not work, throws some kind of error. I didn't bother to read (maybe I should read and file it as a bug to subclipse maintainers ;-(), I knew the tortoisse will work, and you know what, it worked. There was a REVERT option.
So #Tom Brito, try command line, try Tortoisse, and then you can look at the subclipse changelog and file a bug. I think that subclipse just forgets to show us some directory changes and updates (or it is designed not to do it?), but I may be wrong.
Tom,
You might want to try TortoiseSVN, and manually update the project workspace. Find the location of your project directory in your hard drive, and then try TortoiseSVN (or the command line if it's your preference) to do the update.
A frequent cause of this problem is to delete the directory without "informing" SVN. For instance, if you manually delete the directory using the operating system instead of using SVN, you will have this problem.
If you removed the directory before you installed the subversion plug-in, but the project already existed in the repository, you will experiment this problem. A solution, in this case, would be to recreate the directory, updating/committing, and then delete again the directory.
Good luck.
My solution to this was
Delete all items in folder
Commit to repository
Update folder to HEAD
Delete folder in Eclipse
Commit to repository
A bit cumbersome, maybe, but it always works
The only working way in same cases is via command line. The subclipse is still not perfect..
So I get that most of you are frowning at me for not currently using any source control. I want to, I really do, now that I've spent some time reading the questions / answers here. I am a hobby programmer and really don't do much more than tinker, but I've been bitten a couple of times now not having the 'time machine' handy...
I still have to decide which product I'll go with, but that's not relevant to this question.
I'm really struggling with the flow of files under source control, so much so I'm not even sure how to pose the question sensibly.
Currently I have a directory hierarchy where all my PHP files live in a Linux Environment. I edit them there and can hit refresh on my browser to see what happens.
As I understand it, my files now live in a different place. When I want to edit, I check it out and edit away. But what is my substitute for F5? How do I test it? Do I have to check it back in, then hit F5? I admit to a good bit of trial and error in my work. I suspect I'm going to get tired of checking in and out real quick for the frequent small changes I tend to make. I have to be missing something, right?
Can anyone step me through where everything lives and how I test along the way, while keeping true to the goal of having a 'time machine' handy?
Eric Sink has a great series of posts on source control basics. His company (Sourcegear) makes a source control tool called Vault, but the how-to is generally pretty system agnostic.
Don't edit your code on production.
Create a development environment, with the appropriate services (apache w/mod_php).
The application directory within your dev environment is where you do your work.
Put your current production app in there.
Commit this directory to the source control tool. (now you have populated source control with your application)
Make changes in your new development environment, hitting F5 when you want to see/test what you've changed.
Merge/Commit your changes to source control.
Actually, your files, while stored in a source repository (big word for another place on your hard drive, or a hard drive somewhere else), can also exist on your local machine, too, just where they exist now.
So, all files that aren't checked out would be marked as "read only", if you are using VSS (not sure about SVN, CVS, etc). So, you could still run your website by hitting "F5" and it will reload the files where they currently are. If you check one out and are editing it, it becomes NOT read only, and you can change it.
Regardless, the web server that you are running will load readonly/writable files with the same effect.
You still have all the files on your hard drive, ready for F5!
The difference is that you can "checkpoint" your files into the repository. Your daily life doesn't have to change at all.
You can do a "checkout" to the same directory where you currently work so that doesn't have to change. Basically your working directory doesn't need to change.
This is a wildly open ended question because how you use a SCM depends heavily on which SCM you choose. A distributed SCM like git works very differently from a centralized one like Subversion.
svn is way easier to digest for the "new user", but git can be a little more powerful and improve your workflow. Subversion also has really great docs and tool support (like trac), and an online book that you should read:
http://svnbook.red-bean.com/
It will cover the basics of source control management which will help you in some way no matter which SCM you ultimately choose, so I recommend skimming the first few chapters.
edit: Let me point out why people are frowning on you, by the way: SCM is more than simply a "backup of your code". Having "timemachine" is nothing like an SCM. With an SCM you can go back in your change history and see what you actually changed and when which is something you'll never get with blobs of code. I'm sure you've asked yourself on more than one occasion: "how did this code get here?" or "I thought I fixed that bug"-- if you did, thats why you need SCM.
You don't "have" to change your workflow in a drastic way. You could, and in some cases you should, but that's not something version control dictates.
You just use the files as you would normally. Only under version control, once you reach a certain state of "finished" or at least "working" (solved an issue in your issue tracker, finished a certain method, tweaked something, etc), you check it in.
If you have more than one developer working on your codebase, be sure to update regularly, so you're always working against a recent (merged) version of the code.
Here is the general workflow that you'd use with a non-centralized source control system like CVS or Subversion: At first you import your current project into the so-called repository, a versioned storage of all your files. Take care only to import hand-generated files (source, data files, makefiles, project files). Generated files (object files, executables, generated documentation) should not be put into the repository.
Then you have to check out your working copy. As the name implies, this is where you will do all your local edits, where you will compile and where you will point your test server at. It's basically the replacement to where you worked at before. You only need to do these steps once per project (although you could check out multiple working copies, of course.)
This is the basic work cycle: At first you check out all changes made in the repository into your local working copy. When working in a team, this would bring in any changes other team members made since your last check out. Then you do your work. When you've finished with a set of work, you should check out the current version again and resolve possible conflicts due to changes by other team members. (In a disciplined team, this is usually not a problem.) Test, and when everything works as expected you commit (check in) your changes. Then you can continue working, and once you've finished again, check out, resolve conflicts, and check in again. Please note that you should only commit changes that were tested and work. How often you check in is a matter of taste, but a general rule says that you should commit your changes at least once at the end of your day. Personally, I commit my changes much more often than that, basically whenever I made a set of related changes that pass all tests.
Great question. With source control you can still do your "F5" refresh process. But after each edit (or a few minor edits) you want to check your code in so you have a copy backed up.
Depending on the source control system, you don't have to explicitly check out the file each time. Just editing the file will check it out. I've written a visual guide to source control that many people have found useful when grokking the basics.
I would recommend a distributed version control system (mercurial, git, bazaar, darcs) rather than a centralized version control system (cvs, svn). They're much easier to setup and work with.
Try mercurial (which is the VCS that I used to understand how version control works) and then if you like you can even move to git.
There's a really nice introductory tutorial on Mercurial's homepage: Understanding Mercurial. That will introduce you to the basic concepts on VCS and how things work. It's really great. After that I suggest you move on to the Mercurial tutorials: Mercurial tutorial page, which will teach you how to actually use Mercurial. Finally, you have a free ebook that is a really great reference on how to use Mercurial: Distributed Revision Control with Mercurial
If you're feeling more adventurous and want to start off with Git straight away, then this free ebook is a great place to start: Git Magic (Very easy read)
In the end, no matter what VCS tool you choose, what you'll end up doing is the following:
Have a repository that you don't manually edit, it only for the VCS
Have a working directory, where you make your changes as usual.
Change what you like, press F5 as many times as you wish. When you like what you've done and think you would like to save the project the way it is at that very moment (much like you would do when you're, for example, writing something in Word) you can then commit your changes to the repository.
If you ever need to go back to a certain state in your project you now have the power to do so.
And that's pretty much it.
If you are using Subversion, you check out your files once . Then, whenever you have made big changes (or are going to lunch or whatever), you commit them to the server. That way you can keep your old work flow by pressing F5, but every time you commit you save a copy of all the files in their current state in your SVN-repository.
Depends on the source control system you use. For example, for subversion and cvs your files can reside in a remote location, but you always check out your own copy of them locally. This local copy (often referred to as the working copy) are just regular files on the filesystem with some meta-data to let you upload your changes back to the server.
If you are using Subversion here's a good tutorial.
Depending on the source control system, 'checkout' may mean different things. In the SVN world, it just means retrieving (could be an update, could be a new file) the latest copy from the repository. In the source-safe world, that generally means updating the existing file and locking it. The text below uses the SVN meaning:
Using PHP, what you want to do is checkout your entire project/site to a working folder on a test apache site. You should have the repository set up so this can happen with a single checkout, including any necessary sub folders. You checkout your project to set this up one time.
Now you can make your changes and hit F5 to refresh as normal. When you're happy with a set of changes to support a particular fix or feature, you can commit in as a unit (with appropriate comments, of course). This puts the latest version in the repository.
Checking out/committing one file at a time would be a hassle.
A source control system is generally a storage place for your files and their history and usually separate from the files you're currently working on. It depends a bit on the type of version control system but suppose you're using something CVS-like (like subversion), then all your files will live in two (or more) places. You have the files in your local directory, the so called "working copy" and one in the repository, which can be located in another local folder, or on another machine, usually accessed over the network. Usually, after the first import of your files into the repository you check them out under a working folder where you continue working on them. I assume that would be the folder where your PHP files now live.
Now what happens when you've checked out a copy and you made some non-trivial changes that you want to "save"? You simply commit those changes in your working copy to the version control system. Now you have a history of your changes. Should you at any point wish to go back to the version at which you committed those changes, then you can simply revert your working copy to an older revision (the name given to the set of changes that you commit at once).
Note that this is all very CVS/SVN-specific, as GIT would work slightly different. I'd recommend starting with subversion and reading the first few chapters of the very excellent SVN Book to get you started.
This is all very subjective depending on the the source control solution that you decide to use. One that you will definitely want to look into is Subversion.
You mentioned that you're doing PHP, but are you doing it in a Linux environment or Windows? It's not really important, but what I typically did when I worked in a PHP environment was to have a production branch and a development branch. This allowed me to configure a cron job (a scheduled task in Windows) for automatically pulling from the production-ready branch for the production server, while pulling from the development branch for my dev server.
Once you decide on a tool, you should really spend some time learning how it works. The concepts of checking in and checking out don't apply to all source control solutions, for example. Either way, I'd highly recommend that you pick one that permits branching. This article goes over a great (in my opinion) source control model to follow in a production environment.
Of course, I state all this having not "tinkered" in years. I've been doing professional development for some time and my techniques might be overkill for somebody in your position. Not to say that there's anything wrong with that, however.
I just want to add that the system that I think was easiest to set up and work with was Mercurial. If you work alone and not in a team you just initialize it in your normal work folder and then go on from there. The normal flow is to edit any file using your favourite editor and then to a checkin (commit).
I havn't tried GIT but I assume it is very similar. Monotone was a little bit harder to get started with. These are all distributed source control systems.
It sounds like you're asking about how to use source control to manage releases.
Here's some general guidance that's not specific to websites:
Use a local copy for developing changes
Compile (if applicable) and test your changes before checking in
Run automated builds and tests as often as possible (at least daily)
Version your daily builds (have some way of specifying the exact bits of code corresponding to a particular build and test run)
If possible, use separate branches for major releases (or have a development and a release branch)
When necessary, stabilize your code base (define a set of tests such that passing all of those tests means you are confident enough in the quality of your product to release it, then drive toward 0 test failures, i.e. ban any checkins to the release branch other than fixes for the outstanding issues)
When you have a build which has the features you want and has passed all of the necessary tests, deploy it.
If you have a small team, a stable product, a fast build, and efficient, high-quality tests then this entire process might be 100% automated and could take place in minutes.
I recommend Subversion. Setting up a repository and using it is actually fairly trivial, even from the command line. Here's how it would go:
if you haven't setup your repo (repository)
1) Make sure you've got Subversion installed on your server
$ which svn
/usr/bin/svn
which is a tool that tells you the path to another tool. if it returns nothing that tool is not installed on your system
1b) If not, get it
$ apt-get install subversion
apt-get is a tool that installs other tools onto your system
If that's not the right name for subversion in apt, try this
$ apt-cache search subversion
or this
$ apt-cache search svn
Find the right package name and install it using apt-get install packagename
2) Create a new repository on your server
$ cd /path/to/directory/of/repositories
$ svnadmin create my_repository
svnadmin create reponame creates a new repository in the present working directory (pwd) with the name reponame
You are officially done creating your repository
if you have an existing repo, or have finished setting it up
1) Make sure you've got Subversion installed on your local machine per the instructions above
2) Check out the repository to your local machine
$ cd /repos/on/your/local/machine
$ svn co svn+ssh://www.myserver.com/path/to/directory/of/repositories/my_repository
svn co is the command you use to check out a repository
3) Create your initial directory structure (optional)
$ cd /repos/on/your/local/machine
$ cd my_repository
$ svn mkdir branches
$ svn mkdir tags
$ svn mkdir trunk
$ svn commit -m "Initial structure"
svn mkdir runs a regular mkdir and creates a directory in the present working directory with the name you supply after typing svn mkdir and then adds it to the repository.
svn commit -m "" sends your changes to the repository and updates it. Whatever you place in the quotes after -m is the comment for this commit (make it count!).
The "working copy" of your code would go in the trunk directory. branches is used for working on individual projects outside of trunk; each directory in branches is a copy of trunk for a different sub project. tags is used more releases. I suggest just focusing on trunk for a while and getting used to Subversion.
working with your repo
1) Add code to your repository
$ cd /repos/on/your/local/machine
$ svn add my_new_file.ext
$ svn add some/new/directory
$ svn add some/directory/*
$ svn add some/directory/*.ext
The second to last line adds every file in that directory. The last line adds every file with the extension .ext.
2) Check the status of your repository
$ cd /repos/on/your/local/machine
$ svn status
That will tell you if there are any new files, and updated files, and files with conflicts (differences between your local version and the version on the server), etc.
3) Update your local copy of your repository
$ cd /repos/on/your/local/machine
$ svn up
Updating pulls any new changes from the server you don't already have
svn up does care what directory you're in. If you want to update your entire repository, makre sure you're in the root directory of the repository (above trunk)
That's all you really need to know to get started. For more information I recommend you check out the Subversion Book.