I use an open source project to host a site (OrchardCMS) which is available in a GIT repository via CodePlex. I have made a few customizations to the source code that are specific to my implementation and I want to keep preserved and under source control. However the challenge arises when there's a new release of the source engine.
My changes certainly won't go into the blessed repository everyone uses.
Currently I'm using two repositories. I use the CodePlex OrchardCMS repository to get the latest changes from the engine the community uses (and that I contribute some bug fixes to).
I then have my own copy which contains my changes. For this, I am using my own source control (hosted TFS from Microsoft). When an update to the core engine comes out, I XCOPY all the files from the current source to my self-maintained repository and commit them to my project.
However this seems like there should be a better option. Any opinions?
You can use git to have an alternative solution.
You can clone the git main repo and keep it updated with the new relases, and you can keep your local modifications, that aren't to be shared with anyone, on a local branch.
When a new release came out, you simply update your master branch in your git repo an then you can rebase or merge your local modications on top of it.
Related
I'd like to manage the GitHub wiki for my project at the same time as I'm developing the code. For example:
Branches
master (stable versions)
develop (development of next version)
Others... (Possible other dev / feature branches)
Ideally, I'd like the wiki to be contained in a subfolder (e.g. /wiki) of the project. Then when I'm making changes to the code I can also update the wiki as the same time (code + documentation change). It'd also mean that all my development code and documentation would be self-contained in the "develop" branch until I merge with the "master" branch. Hopefully, even if via a manual process, the GitHub wiki would then be updated after the merge with master to reflect the changes.
I've taken a look at Git's submodule feature, but from what I understand that usually points at a single revision. I'd like to somehow follow my code development so branching and merging would work as normal.
As explained in "True nature of submodules", you can make modifications and updates within a submodule, as long as you commit also the parent repo in order to record the new state of your "wiki" sub-repo.
If you intend to use Gollum to display and work on your GitHub wiki while it's on your local machine (you probably should), then you will have a trouble if you use submodules.
Gollum wants to do local commits to your local Git repository (but not pushes), but in a submodule .git is actually a file containing the local repository, not a true Git repository. This causes Gollum to break.
Submodules also have the problems that the versions aren't coupled to the parent repository, and they aren't completely de-coupled. It a nuisance to have the source code repository to want to push the new wiki version number (but not the wiki contents) every time you make a documentation change.
The solution I use is simply to clone the wiki repository into a directory inside the main project directory and add it to .gitignore. By using a consistent name for the directory across projects (e.g. github-wiki), the chance is minimized that the wiki won't be in .gitignore and gets accidentally uploaded into the main repository.
For consistency, his approach also works well for GitHub pages, although it's unnecessary as they don't experience the problem with Gollum.
I'm trying to set up EGit with Eclipse and I've used neither of them before. I understand the basics around Git and Eclipse is more or less just another IDE. The problem I'm having is setting up a reasonable work environment.
I have file-server at home which I want to use as a Bare repository which I push and pull changes to. To test it out I've done the setup locally.
I have a bare repository created through the Git Repository perspective.
I've cloned that repository into a local non-bare repository.
I've created a project in a subdir of the non-bare repository (is this the way to go? Is it possible to do have the project directly in the workspace with the .git folder within it? So far I've had a lot of trouble with it when trying to create an Eclipse project out of it. What is the proper way to do it?)
I've made some changes to this cloned repository and added the indexes, committed the changes and attempted to push the changes to upstream.
The thing is that no changes are made to upstream. Would someone like to explain the procedure in doing the push so that I'm not misunderstanding something? Or am I completely wrong on utilizing a bare repository instead of just working non-bare?
As mentioned in this tutorial, you create your Git repo right where your project is (ie your .classpath and .project files are).
Pushing to a bare repo is a good idea (see the links mentioned in "Git - pull & push - production server")
You need though to specify what you want to push:
Click at least on "Add all branch spec".
I've recently been looking at using Git to eventually replace the CVS repository we have at work. However after watching Linus Torvalds' video on YouTube about Git it seems that every tutorial I find suggests using Git in the same way CVS is used except that you have a local repository which I agree is very useful for speed and distribution.
However the tutorials suggest that what you do is each clone the repository you want to develop on from a remote location and that when changes are made you commit locally building up a history to help with merge control. When you are ready to commit your changes you then push them to the remote location, but first you fetch changes to check for merge conflicts (just like CVS).
However in Linus' video he describe the functionality of Git as a group of developers working on some code pushing and fetching from each other as needed, not using a remote location i.e. a centralized location. He also describes people pushing their changes out to verifiers who fetch and push code also. So you can see it's possible to create scalable structure within a company also.
My question is can anybody point me in the direction of some tutorials that actually explain how to do this distributed development of code using Git so that developers push and fetch code from each other with out committing to the remote repository and if possible it would be very nice to have this tutorials Eclipsed based.
Thanks in advance,
Alexei Blue.
I don't know any specific tutorial about this. In general, for connecting to a repository, you have to be running a git server that listens (and authenticates) to git requests.
To have a specific repository for each developer is possible - but each repository needs that server component. It is possible to store multiple repositories on the same computer, that allows reducing the number of servers required.
However, for other reasons it is beneficial to have some kind of central structure (e.g. a repository for stuff to be released; or a repository for stuff not verified yet). This structure is not required to be a single central repository, but multiple ones with well-defined workflows regarding the data move between repositories (e.g. if code from the verification repository is validated, it should be pushed to the release repository).
In other words, you should be ready to create Git servers (e.g. see http://tumblr.intranation.com/post/766290565/how-set-up-your-own-private-git-server-linux for details; but there are other tutorials for this as well), and define workflows for your own company to use it.
Additionally, I recommend looking at AlBlue's blog series called Git Tip of the Week.
Finally, to ease the introduction I suggest to first introduce Git as a direct replacement for CVS, and then present the other changes one by one.
Take a look at alblue's blog entry on Gerrit
This shows a workflow different from the classic centralized server such as CVS or SVN. Superficially it looks similar as you pull the source from a central Git server, but you push your commits to the Gerrit server that can compile and test the code to make sure it works before eventually pushing the changes to the central Git server.
Now instead of pushing the changes to Gerrit, you could have pushed the code to your pair programming buddy and he could have manually reviewed and tested the code.
Or maybe you're going on holiday and a colleague will finish the task you've started. No problem, just push your changes to their Git repo.
Git doesn't treat any of these other Git instances any different from each other. From Git's perspective, none of them are special.
I am working on an enormous project ("the project") which is open-source, and I am changing the project but don't have a permission to commit. I'm looking for strategies for maintaining my own branch of the project. Some issues I am contemplating:
How to put my own work in a version control system, given that I'm altering the project's source code, adding new files and so on.
How to keep in sync with the project without having to manually merge my own changes over and over again.
I've never been in this situation - I've always maintained my complete project in some version control system. My plan right now is something like that:
Creating a directory tree in my SVN, similar to the one in the project.
Keeping all the changed files (and only them) in my svn.
Every time I decide to sync with the new baseline of the project, I'll do a checkout, merge my svn tree into the new version, test, then commit my changes to my svn and distribute them along with the latest project baseline.
The problems here are ENDLESS. Way too many manual steps, more and more work over time, and so on. The correct way to go would be, of course, to be a part of the original project, but this seems to be quite irrelevant right now for various reasons and is out of the question.
Ideas?
I'd use git or mercurial for this; simply import the project into git or mercurial, and merge the upstream changes into a branch in your project for easy merging into your trunk.
If the upstream project has a repository of their own, the import is even easier. Both git and mercurial have support for directly importing other version control systems. I did this recently to adapt an existing project that lives in SVN: https://github.com/mjpieters/rod.recipe.rabbitmq
Note that that project has an 'upstream' branch. That particular project has now accepted my proposed changes after reviewing the changes in github.com.
There are a few questions here on SO on the subject:
Fork and synchronize Google Code Subversion repository into GitHub
Tracking upstream svn changes with git-svn and github?
Best way to fork SVN project with Git
It should be trivial to create a similar setup with mercurial.
You can use git to maintain your source control on your local system. In fact Git can be used to maintain just about any directory under version control. There is no need to sync to anything, git maintains all changes locally.
If you need to commit to SVN check out the documentation http://git-scm.com/docs/git-svn
The question
An open source program uses CVS for version control. I would like to make a number of bug-fixes and submit patch bombs to the developers with commit access. I would also like to maintain my own semi-private fork that mainly tracks the main code-base but that includes my own features (these features, right now, should not be incorporated into the main code-base.)
I prefer to use mercurial for my own version control needs, but I am open to other version control systems if necessary.
I'd like to:
Be able to easily create patch-bombs against the current CVS source with my own bug-fixes
Keep track of history on my own features
Have fixes and improvements from the main tree easily incorporated in my new-feature fork
Easily apply my own bug-fixes to my new-feature fork
Be able to work and track change history without an Internet connection.
What suggestions do you have for doing this?
My current idea
My own best guess is below, to give you a better idea of what I am thinking about.
I will have 3 mercurial repositories.
The first two repos are managed as specified at (https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS). One just mirrors the latest changes from the CVS upstream. I do "cvs update" then "hg commit" in this repo. The second repo holds my bug-fixes as patches using the mq extension and I pull from the the first repo and re-base my patches every so often. When my patches are incorporated into the main tree, I remove the patches from the patch queue/make them permanent commits.
The third repo is my local fork. It will start out as a clone of the first repo. Then each time I do an update of the first repo, I'll pull from it into repo 3. My own features will be directly present as commits in this repo. When I fix a bug, I'll export a patch from repo 2 and apply it to the appropriate pull from repo 1.
I have used Git to manage changes on top of a CVS repository in a similar way. My solution in Git uses local branches instead of multiple repositories, but it sounds essentially similar to your proposed idea.
I found that this arrangement works best if you commit all the CVS metadata (in the CVS/) subdirectories) to your mirrored repository. This means that the CVS metadata gets replicated in the other repositories, but it doesn't cause any harm (and lets you run commands like cvs diff if you need to).