My client is using SVN and my company is using Git (central bare Git repo). So I have the task to sync both servers. I can't use SubGit , because I can't do any modification on either server.
I successfully used git-svn to download the SVN to my local Git repo (using TortoiseGit). But I can't figure out how to set up a remote upstream to the central Git Repository (using Egit in Eclipse).
Is it possible to set up a remote branch, so I can check in the SVN stuff from my local Git into the central Git repo? How?
thanks.
If I understand correctly, you can't update hooks in SVN and Git repositories. That complicates the task a lot, because you can't reject pushes Git if someone is committing to SVN at the same moment and vice versa.
I think, that git-svn is not a solution because on sending commits to SVN ("git svn dcommit") it changes Git commit SHA-1 to add git-svn-id: signature. As result when one pushes commit C to your Git repository, you fetch that commit to your git-svn repsository, run "git svn dcommit", it translates it to SVN and adds git-svn-id: signature to commit message thus changing commit SHA-1, so you'll get another commit C' in git-svn repository. After that C' should be sent back to the Git repository, and after that the user that pushed C should download C' and replace C with C' in his working copy. So you won't have easy and transparent synchronization.
With SubGit you can reduce your problem to synchronization of 2 Git repositories by creation of an "intermediate" Git repository with SubGit installed into it. Synchronization of 2 Git repositories is a simpler task (and there's a lot of solutions on the internet) but it's still isn't a piece of cake, because 2 different users can push into both repositories simultaneously (and you can't discard one of the push, because you can't create hooks in the repositories). If these changes are conflicting, you can resolve that only manually, and I'm afraid this is the best you can do: create a repository with 2 remote and using a script constantly fetch changes from one of them and push the changes to another one and vice versa (and notify the administrator and stop synchronization on simultaneous conflicting changes).
Disclaimer: I can be biased because I'm one of SubGit developers.
Related
I have project A. The project A is in perforce as well as in github( Business decision). They are both out of sync. I see that I can use git-p4 tool http://git-scm.com/docs/git-p4 to submit git changes to perforce. Problem is first instruction of it says is:
git p4 clone //depot/path/project
This command will create a new repo in git hub. I do not want that. I want my existing perforce depot to connect to exiting github repo and then sync files from github to perforce. Is it possible?
No. git p4 is basically just a wrapper around Perforce. It reads changes to a Git repo and issues the proper Perforce commands to commit them (and vice-versa -- it reads changes to a Perforce checkout and issues the proper Git commands to update a Git repo accordingly). So you need to have a Perforce checkout and a local Git repo that can talk to that Perforce checkout.
Fundamentally you have two different histories for the same project, so you need to find some way to reconcile them.
git-p4 can sync from Perforce (create a new git repository), then you can add a new remote pointing to github, and sync the branches from there.
However that doesn't help with the problem of merging the histories.
You can either:
Go with Perforce, and rewrite github history
Go with Github history, and get your perforce admin/Perforce (company) to rewrite your Perforce history.
2 is probably (politically) impossible. May be impossible technically. Perforce is designed to prevent history from being altered.
1 will break anyone cloned from your github repository.
You may want to take a look at Git Fusion, which is a bridge between Git and Perforce:
http://www.perforce.com/git-fusion
This KB article gives an example of how you may wish to work with a project that is both in Perforce and a public Git repo:
http://answers.perforce.com/articles/KB/7481/
Hope this helps!
I'm using Mercurial with TortoiseHg on a Windwos host.
We have a central repository for the team and it must always be in a stable state.
Now I'm working on a feature with a colleague and we want to merge our work, without going via the central repository because our work isn't stable yet.
So we have a common ancestor, then we have individual commits to our local repos and we need to merge this work and test it, before pushing it to the central repo.
How do we do that?
As a an additonal difficulty, I'm working on Windows with TortoiseHg, while my colleague is on a Linux box. We're both only basic users of Hg, so apologies if this is a question with an evident solution. For me it isn't.
You can use named branches and create special named branch (pushed to central repo) for your WIP
You can use Mercurial in true DVCS-way:
Start embedded web-server on both sides hg serve in the Working Directory
Get URL of repo
Pull from remote side hg pull URL-OF-REMOTE-REPO
I am trying to find out what would be the best way to set up egit repos for mutliple developers.
I found some arguments to set up independant repos for each developer and then the recommendation to merge the files by setting the respective external upstream repo to eg developer B in Eclipse of developer A so A can pull and merge with B. However A then needs to change the repo back to his own all the time. And switching upstream repos in the settings is quite cumbersome.
Alternatively all developers could work off the same repo in different braches - then merging would be easier since noone has to go to settings and change the upstream repo. On the other side this is also kind of "dangerous" since every developer is working on the same repo without restrictions (so I heard)
Which way is better in the long run?
In the long run, having one upstream repository is easier to manage.
Each developer can make their own branches locally.
They should agree on a common branch to push to though. It can be master, or a feature branch (if a few of them are collaborating to a specific feature).
The idea is, before each push, to pull --rebase that branch from the upstream repo in order to replay your local work (the commits you haven't pushed already) on top of upstream/branch (git pull --rebase will fetch and then rebase your local work on top of what has just been fetch).
That way, a developer will only push commits which will be merged on upstream as a fast-forward merge.
In EGit terms, that pull --rebase is configured when you create a tracking branch.
Rebase: When pulling, new changes will be fetched from upstream and the remote tracking branch will be updated. Then the current local branch will be rebased onto the updated remote tracking branch
I am working on a project that is set up with each group having a server-side clone of our main mercurial repository. The workflow we have been using involves developing on laptops, committing and pushing to the server-side clone repositories and then pulling those changes to a powerful remote machine to run our tests. Once the changes are ready to be shared with the rest of the group, the main server-side clone is pulled and into the local repository and the local repository is rebased against the main clone. The changes can then be pushed to the main remote clone and the history will show a linear history.
The problem is then that the personal server-side clone is totally out of sync with the local repository because it was not rebased. We aren't using proper branches, so merge+rebase and transplant/graft seem to not be what we would use to get the repositories back in sync.
The server-side clone needs to have the same history as the the local repository or it will pull and push ALL of the change sets and be a time consuming mess of resolving non-existent conflicts. How would one get the server-side clone to have the same history as the main and local repositories without stripping and pulling from main? Ideally, we would not have to log into the server.
You can only pull from the 'main' repo to get its history, but this won't delete the not-rebased history from your dev server and local repos.
The only way to have only 'main' history is stripping other repos (or even re-cloning them), and this must be done simultaneously for all repos.
P.s. And don't rebase. It's for private repos only.
Rebasing is deterministic, so you could re-do the rebase in the client clones.
The only cause for concern is if the rebase triggered a merge resolution — in that case you'll have to resolve the merge the same way in the client. Doing that without peeking at the code on the server could be difficult.
I have read :
"Best practices for using git with CVS"
"How to export revision history from mercurial or git to cvs?"
, and neither suit my needs.
At work we use a remote CVS repo. Access to this repo is handled via eclipse CVS tools, and in-house eclipse plugins that are built ontop of team tools for eclipse. This means we can't move to a better vcs.
However I would like to use Git on my local machine (to enable personal branching) such that I can accomplish the following:
Create branches in Git and then once finished and merged back into my local trunk, commit back to the cvs repo using the eclipse team tools etc.
My plan is something along the following lines:
Copy the checked out files to another folder [gitRepo].
Create a master git repo in gitRepo
Branch in gitRepo and make changes.
Commit to gitRepo
Copy gitRepo back to checked out files
Sync with remote cvs.
I was planning on using eGit for eclipse however I believe that the CVS and .git files will compete for ownership of the versioning.
Are there any tools or suggested work flows to help me manage this? Also how well does Git play with CVS files. And vice versa since I don’t want them to infect each other.
The reason the former links are of no use is they commit straight to the cvs repo from the git repo and this worries me as I do not wish to infect the cvs repo by accident.
It should also be said that changes in the GitRepo do not need to persist into the CVS repo, for example I don’t need to see every push to the git repo reflected in the remote CVS.
~Thanks for reading.
You perfectly can create a git repo directly within a CVS workspace (much like directly within any other VCS tool.
Make sure git will ignore any .cvs resources, and make sure CVS will ignore the .git.
Any Git commit won't be directly reflected in CVS.
The only trick is for Eclipse to display only Git or only CVS informations and label decoration.
For that I would configure two different Eclipse perspectives in which I will de-activate one or the other VCS tool.
I have done exactly this at work and I found the following practices helpful:
Keep any one (master in my case) branch always in sync with CVS. Do not use this branch for your development. Periodically update this branch to get the changes made by the rest of the team. If these changes are relevant to your current work do a merge master from your dev (or any other appropriate) branch.
When you are ready to check in to CVS switch to the master branch and merge the changes from the appropriate branch (dev, feature etc. as appropriate). Run your tests!
You employer most likely will keep a back up of the CVS repos. You will have to find a way to keep your git repo backed up. One way is to add a mirror repository in a Dropbox folder and use a post-commit hook to update it after each commit.
Before you leave work switch to the master branch. I once made the mistake of running CVS up -d on a dev branch in the morning and ended up quite confused. Adding a script to automatically switch to master before updating helps.