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).
Related
I'm using Bazaar quite some time now, but at the moment I'm searching a solution to the following problem:
Assuming you've got several developers with everyone developing in its own branch, like this:
Project
|
|----Branch 1
|
|----Branch 2
|
...
Now, we've got a project manager who wants to have an overview over all branches.
Is there any possibility (using only bzr functions) that he can manage those branches at once?
With "manage", I mean update, commit and perhaps even checkout (last one could perhaps be done with multi-pull but I think this would overwrite existing local data)
Greetings Florian
P.S. I know that this use-case could easily be achieved with SVN (by simply using subdirectories - but without the features of a dvcs) or more or less easily with shell-scripts (something like bzr list-branches|xargs bzr update), but I'd prefer a built-in bzr function
You can see all the branches in a directory tree with:
bzr branches -R /path/to/base/dir
However this works only on the local filesystem. If you need to find branches in a remote system, you need to run the command through ssh or something.
Once you have the list of branches, the manager should branch from them into his local shared repository, preferably configured with the --no-trees option for space efficiency. Existing branches should be pulled instead (using multi-pull for example), removed branches should be removed.
Once he has the branches, the easiest way to overview is using Bazaar Explorer. Open the shared repository location. I especially like the Log button, which will show the tree of logs.
When you say commit... The manager should not commit to the developer branches. If fixes are needed it's better to ask the developer to fix it, otherwise the manager will always have to clean up their mess for them. The manager should only merge other branches to the trunk/main/master. In other words use the gatekeeper workflow.
You can try the bzr-externals plugin or the bzr-scmproj plugin.
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.
We have a git-svn repository.
I had no troubles to update the trunk with my local changes (commit + push or commit + merge), however sometimes my colleagues make some fixes in the code and update the git-svn and i want to take his changes without committing mine, since the code is not yet ready for commit (even locally, i might want to revert some of it). I can;t find a way to get his code and merge conflicting changes (i work with 'tower' git client on mac os x).
Any way to do the same action an svn 'update' command will do ?
10x.
You could stash your current work in order to get a pristine working tree, allowing you to do your git-svn update.
You can see a similar technique in "How to handle IDE project files with git-svn".
Another alternative is through Stacked Git.
See "How do I track local-only changes/change sets with git-svn?".
StGit is a Python application providing similar functionality to Quilt (i.e. pushing/popping patches to/from a stack) on top of Git. *
These operations are performed using Git commands and the patches are stored as Git commit objects, allowing easy merging of the StGit patches into other repositories using standard Git functionality.
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
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