I have multiple eclipse projects that are tightly related. I want to add them in a mercurial repo (repos).
Option1:
Repo per project - too many repos and then I loose my ability to group projects because all projects are repos.
Option2:
Multiple projects in one repo as folders.
First, eclipse's plugin cannot add many project into one repo (this tutorial fails for me, there aren't many tutorials on the subject, I guess I can do this from the command line).
Also I cannot pull/push per project. I have to perform this operation per repo. I miss SVN in this regard.
Option3:
mercurial forest - no longer actively supported.
Option4:
Subrepository - feature of last resort.
What is the best practice?
It looks like a simple case like this doesn't have a straightforward answer. Is mercurial actively developed?
Second question first: Mercurial is actively developed. Here's the source update log.
Option 2 is your best bet. Like the guide you linked to shows, the repository folder (with the .hg folder inside of it...'n-projects-ws-repo' in this example) means that this folder--and every file and folder in this folder structure--is part of the repository. The diagram they show is two subfolders called org.ekkescorner.one and org.ekkescorner.two. These are two projects under the repo called 'n-projects-ws-repo'.
Related
I am sure this is a RTFM thing, but after a few days of research I still cannot determine the correct (or best) workflow for this.
I have an Eclipse Workspace with a number of Java Projects in it and a number of C++/Arduino projects.
I want to start using GitHub as an online repository (easily reachable from outside my private LAN dev environment) for my projects
I was thinking I would like a separate C++/Arduino and Java GitHub repos. More could come for Python, PowerShell, etc. (But I will happily entertain other recommendations for repo structures).
Outside of the actual mechanics of using Egit, I cannot figure out the most appropriate workflow/folder structure for accomplishing this. Should I create local Git repos and push to GitHub as a remote? Should I use GitHub's web interface to import the entire Eclipse Workspace? Should I work directly with the Eclipse Workspace or have separate Git folders?
I guess the crux of my problem is that after reading a few related posts on this site I get conflicting advice about creating a local repo from the Eclipse workspace vs. a separate local repo. I think I need to understand this distinction first before I ultimately determine the best overall workflow.
I apologize for the broad nature of this question, but I hope that the community can help me narrow the workflow process design (or the question itself).
Two things up front:
Never put your entire workspace in source control; projects: yes, workspace: no. The .metadata folder contains data specific to that location and your machine, and that's ignoring any potential security risks with making it public.
eGit works with your git clones' own metadata, so if you're more comfortable doing certain things from the command line, go for it. I know I am, but I still appreciate the UI and decorations that eGit provides. Just make sure any automatic refresh/update preferences on the Workspace or Git preference pages are turned on.
You probably want the repository to contain multiple projects, rather than having a separate repository for each one. That way histories and changes that belong together are together. Nest the layout however you like, but remember that you're not constrained to a single repository for everything, either.
I don't know that there's a best practice for this, especially with projects that already exist, but projects should themselves be relocatable. My recommendation, after backing it all up:
Make the Github projects, clone their repos locally. I do it this way, from the command line, to save me any headaches with the history, remotes, and refs. I don't think you can modify the repository metadata in this method, though.
Move the workspace projects into the local clone. You can delete them from the workspace (be sure not to delete the underlying files), physically move the directories while outside of Eclipse, and then import them as projects back in from the Git Repositories View--unless they're Maven projects, in which case it's better to use M2E's import wizard.
Stage, commit, and push the projects up to the remote origin. For Java projects, don't forget to set the JRE System Library in the Java Build Path to use an Execution Environment. It's a simple bit of indirection that makes them more portable across machines.
Question:
How do you commit a single project (of many) in pydev (eclipse Indigo 3.7.2) using egit?
Problem Specifics:
I have many independent projects that currently all go to the same repository. I work on them all sporadically and need to commit them individually (not all at once) since sometimes only 1 project is ready. Unfortunately, when I right click on a single project folder, select Team, then Commit, git tries to commit all of my projects (not just the one I selected).
Conjectures:
Do I need to have the projects in separate local repositories? If that is the case, what is the best practice for segregating projects that eventually end up in the same bit bucket repository? Or, should I just have multiple bit bucket repositories?
I have one Eclipse Workspace containing two projects.
- The first is my actual library.
- The second is example code for using the library.
When I push this code to GitHub, I don't want two separate projects, I want the example code to go into an "example" folder of the second library.
How and where would I do this? From Eclipse, GIT, or GitHub?
Or is there a better way of including sample code in GitHub projects? (the example code doesn't actually need any version control)
What if I decide to add more than one sample project?
You can apply source-control to projects in one wokspace, project by project is that pointng to different nodes
Please see Tutorials Git with Eclipse (EGit) and Git, Github and Egit Eclipse integration
Hopes that helps
After more experience with Git and GitHub over my belt, now days I usually place any example code in a separate orphaned branch.
This has several benefits over placing examples into a sub-folder. Primarily, any changes or additions to the examples (Which obviously aren't critical to the library) won't give unnecessary notices of the library code being "changed", or even "ahead" of code in any forks. Also, this setup works well with Eclipse, since both projects will then have their own separate local repositories.
It's also a good idea (and I often forget) to point out this "example" branch in the README.
I want to store a project in Mercurial that contains external code (which can be modified by me) coming from Git and SVN repositories. In SVN I would solve this with vendor branches and copy the code around, but I understood that in Mercurial it's better to have different repositories for different projects, and pull between them when needed.
The project layout will be like this:
- externalLibraryA [comes from a SVN repo]
- ...with some extra files from me
- externalLibraryB [comes from a SVN repo]
- ...with some extra files from me
- externalPluginForExternalLibraryB [comes from a Git repo]
In Subversion I would create vendor dir and a trunk dir, copy all external libraries first in vendor, and then in the right place in trunk. (I think) I can do this in Mercurial too, with subrepositories, but is this the best way to do this?
I tried setting up different repositories for the external libraries, but then it seems I can't pull the externalLibraryARepo into the externalLibraryA directory of my main repository? It goes in the main directory, which is not what I want. I can also create a Mercurial mirror repository and include it as a subrepo in my main repository, but then the changes in this subdirectory go to the mirror repository, while I want them to stay in the main repository.
I'd probably just store this in one repository - note that in the link you give they are using their build system in the end to bring together the binary output from the different repos. I'm not clear on their rationale there.
If the underlying problem you're trying to solve is how to update the externals in a clean way, I'd probably use anonymous branching for that.
I.e. add the external lib to your project, and your modifications. Make sure it works. Tag with ExternalA-v1.0. Hack away on your actual project. Now ExternalA, Inc. has a new version of their stuff. Update your repo to ExternalA-v1.0 tag. Import their new version and apply your modifications on top. Commit. Now you have two heads: one with the latest version of your code (that works with ExternalA-v1.0) and one with the latest version of ExternalA (that does not work with your code, maybe). So then you merge and reconcile the two. Tag again, now with ExternalA-v2.0. Repeat as needed.
You can still keep your externals in separate repositories, but I assume that the project that is using those does not need to be up to date with changes there all the time - looks like the whole point of vendor branches is to have some point of isolation between dependee and dependants. Of course, moving the changes from the externalA project to the project that is using that will then be a manual affair (well, a copy, much like in SVN really).
It depends on whether your vendor code is going to be customized by your team or not. Our teams have had a great deal of success maintaining a named "vendor" branch on repositories with our own customizations on branches named by project name. This vendor code is then easily included in a project as a subrepository.
A caveat to this approach: if active development is going on in the subrepository, best keep it to directly editing the subrepository as a separate clone, otherwise it becomes necessary to pay close attention to the top-level repository so you don't inadvertantly bump your .hgsubstate forward to the wrong revision and break your build.
Watch out for merges of the top-level repository (your project) between versions which point to different named branches of your subrepository, as this can result in a merge between the "vendor" and "project" branches in the subrepository as it recurses, which may not be desirable.
Note that this functionality may change in the future as well, as some "warm" discussions have been taking place in recent months on the mercurial-devel mailing lists about the future of subrepository recursion.
edit:
I just saw this discussion in the related links as well, which seems relevant: https://stackoverflow.com/a/3998791/1186771
I've just started using subversion, and have read the official documentation (svn book), cheat sheet and a couple of guides. I know how to install subversion (in linux), create a repository (svnadmin create), and import my Eclipse project into the repository (SVN import), view the repository files (using svn list).
But I am unable to understand some of the other terminologies. For example, after importing my Eclipse project into the newly created repository I have made changes to my Eclipse project (more than 1 file). Now, how should I update the repository with this added files/changes made to my Eclipse project?
The svn update command brings the changes from the repository into your working copy - which is the opposite of what I want i.e. bring the changes I made in my Eclipse project into the previously imported project in repository. If I am correct, you update the repository more often (as you keep extending your project implementation) than your current project (with update).
Also, I do not understand when would you use svn merge. The svn book states it applies the differences between 2 sources to a working copy. Is there a scenario which would explain this?
Finally, can I have more than 1 project checked into the repository? Or is it better to create a new repository for each project?
The term you are looking for is "commit".
Subversion does not exclusively lock a file for editing (though there is a command to do this if you really, really want to). So it is possible that you will need to merge two different users' sets of edits on a file, or even edits from two different working copies in two different locations on your machine.
Multiple projects is fine. Best approach IMHO is repository/project/trunk etc rather than repository/trunk/project.
Three things about SVN you should know:
Trunk - The main version of your code
Tags - 'Tagged' Versions of your code (i.e. v1.2.5-release)
Branches - Forks of the code for divergent development paths. We typically fork new branches to work on different versions, so if the current version is 1.2.4, you'd branch for 1.3's development. So if emergency changes to 1.2 need to be made (i.e. 1.2.5) you can work on it without worrying about what you broke by refactoring / feature adding in your 1.3 branch. The merge operation is designed so you can merge 1.3's branch back into trunk when you're ready to release 1.3, or a similar operation. You can also merge individual files (if two or more developers edited the same file at the same time and now you need to 'merge' the changes into the same file.
Each project in your repository should have 3 folders in it:
/trunk
/branches
/tags
These house the three points above. You don't have to have these folders, but you should. Other more mature VCS like Mericual/Git have the concepts of tags and branches baked into the system. In SVN these are more of a convention/reccomendation.
Terminology
Working Copy - The copy on your hard-drive, that contains all your edits, etc...
Add - Registers a file for tracking in version control
Update - Updates the working copy with changes from the server repository
Commit - Updates the server repository with changes from the working copy
Switch - Replaces the working copy with another folder within the server repository
Diff - Does a differential analysis of two files / versions of a file to see the changes between them.
Merge - Attempts to apply the changes from one or more files into another, highlighting conflicts.
Patch - A set of differences that can be used to update a file.
You commit changes to the repository
Merge is useful when you need to maintain two branches of a repository. For examples v1.x with most recent security fixes and the alpha version 2. That allows you to make the fixes in the 1.x code, whith the resulting binary for existing customers, and you can merge the changes into version 2 so fixing the bugs that weren't already caught.
I suggest you look around for 'typical svn workflows'. They will give you the big picture of the 'most common tasks'.
What you want to do is 'commit' the changes made to your files to the repository.
You need to merge in case of a conflict (when 2 or more people are working on a project and commit to the same repo. conflicts might arise).
Check the available articles on SVN kai remember to read about the sample/typical workflows or working scenarios with SVN.
Fully agree with David, but as far as question 3 is concerned, personally, I would distinguish between use cases:
Production: One project per repository. And do get warm with the mentioned tag/trunk/branch concept, it really helps a lot
Testing: I have one single repository where I have put virtually all my experimental codes (approx. 10 languages with x codes per language). Reason is: One experimental code takes me 1-2 minutes, creating a repository on a remote host, using ssh-security sometimes takes longer ;-)
Cheers
EL