I think it would be easier to submit patches (on multiple files) if git was used instead.
It would also give all non project members ability to do local checkins when prototyping new functionality.
I could not agree more. It is just a matter of not having too much time. Do you know how to do it? Can you assist?
I have never done it before, but with a bit of support I could give it a try.
I have just (by following a recepie) converted all the modules to separate git repositories on my linux server. I plan to create a super git repository by importing all the other repositories as subprojects. I am not sure if this is the best way to go in this situation.
Anyone knowing pros and cons with git subprojects compared to putting all eclipse-clearcase code in one repository? I also suspect there will be issues with the non eclipse parts that belongs to the other sourceforge project.
I will be back when I have done some more testing and googling.
My experience with git is limited ( reading code). I guess we need to check and see what the other projects have done.
keep in touch and thanks for the support.
I need admin rights to continue.
I will give you admin rights. Be careful :-)
Any luck with this?
Yes, I just did another rsync and re migrated the repository this evening.
I am not sure I get the user name transformation completely correct.
There happens to be an example that looks like how to transform a name that includes the letter ö, but since my Ubuntu installation has some problem with the LOCALE, I can not verify that it really works.
The next step is to push the repo back to sourceforge. Do you think we should disable git for other developers to prevent problems if we need to whipe the git repo and start all over with the migration?
It looks like I only have developer access, but that seems to be enough for the moment.
I guess the LOCALE problem is no big issue.
We are the only developers so please goahead and push repo back to sf site.
Admin is for admin of this site. Has nothing to do with repos.
Let me know when you can have a copy in git then I can test it.
Now I have pushed:
git push origin master
Counting objects: 9425, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (1707/1707), done.
Writing objects: 100% (9425/9425), 9.21 MiB | 94 KiB/s, done.
Total 9425 (delta 5646), reused 9324 (delta 5581)
* [new branch] master -> master
Things left to do according to the instruction: http://blog.gorwits.me.uk/2011/06/22/migrate-sourceforge-cvs-repository-to-git/
* Change the lightweigt tags into annotated tags.
* Setup some post-commit hooks, if we want/need them.
Nice work. I just caught a glimpse of it. Looks good. I have not worked with git but I think I will learn with time.
- Change the lightweigt tags into annotated tags
[Mike] I really don't know what the difference is but I need to do some reading about it.
- Setup some post-commit hooks, if we want/need them
[Mike] I am not sure we need them. We had no in cvs.
I am working on a branch now i cvs and would like to get my work into git. How can I do that? Any ideas?
This is my first contact with git as well.
I handled the changes I had in the following way.
* begun with cloning from sf.
* then I just copied all changed files into the git managed code, replacing whatever was there.
* then I branched
* then I carefully examined all the changes in the files.
* since I could not see other changes than the one I had made I knew I did not had a merge situation,
so I added the files to the staging area and commited them from there.
While doing this I read through the manuals, and I am quite impressed of all the features available in git... I think this will be really good.
Regarding the final TODOs.
* I can not either tell what we will gain by transforming all the old lightweight tags into annotated ones. It looks like we can postpone that action until we know what it is good for and what to annotate with.
* I do not see a need for post commit hooks either.
Before creating too many branches, do you think we should agree on a branching/merging model? I have found these links on the subject:
I wait to push my "feature branches" until I know how you think about these issues.
Could you disable write access to cvs when you think it is appropriate?
Thanks for links. I will do some reading and get back to you.
I did some reading and checked with other people and they thought that this
was the best for our purpose ( not so large project). So we will for this.
I will convert the depending project clearcase-java before we can start development. No one is commiting code to cvs ( only me ). I will soon make it read-only.
I have added some information on out wiki and we need to update as we adapt the branching strategy as we work.
I have setup the dependant project clearcase-java in git too.
So we should have a working env. now.
Please test and see if you can import all projects into Eclipse.
I have added a development branch for both:
clearcase-java and eclipse-ccase projects.
I managed to import both projects (one at a time) into a new Eclipse workspace, by doing two File->Import...
Works great it seems. I had some trouble doing this last week, but now it works.
I will push my changes into separate feature branches next time I log into the computer containing them.
This is great, thanks.
Ok so we can close this and then try to update the wiki as we go along working with the code.