does dmca push us further toward distributed rev control?

[Snacko]

soft reset is mostly used to back out some commits while leaving your files as is (local branches)

if you do it on a tracking branch and push it you end up with a new HEAD and a detached HEAD (the problem you posted about in other thread);

Personally I don't use egit much as I prefer to use command line. I also prefer to use p4merge for merging so this only from description what those features should do:
Fetch -> download new changes (doesn't merge them)
Merge -> merge a branch into your current checkout branch; you use this if you only fetch
Pull -> fetch + automatic merge
Team Synchronize -> I never used this, but it shows the differences between what you have and a chosen git/svn/other vcs revision; also shows conflicts

Automatic merge occurs when you pull on a branch that is a tracking branch and has commits that diverged the history. You can read more http://www.kernel.org/pub/software/scm/ ... -pull.html as with other git documentation.

[Rob Cashwalker]

Dave,

Goblin Hero put up an SVN and would like us to at least try it, to make sure its operational. Commit privileges will be tied to your forum username and password, but I'm waiting to find out how to add users. Once I have all that, I'll post the details, could you then try to make an upload based on our git + svn history?

[jendave]

Dave,

Goblin Hero put up an SVN and would like us to at least try it, to make sure its operational. Commit privileges will be tied to your forum username and password, but I'm waiting to find out how to add users. Once I have all that, I'll post the details, could you then try to make an upload based on our git + svn history?

Sure, what is the SVN repo url? You can PM me.

[Braids]

invalid LOC header (bad signature) . . .
Sounds like you have a corrupt miglayout jar.

try removing the "C:\Users\jeff\.m2\repository\com\miglayout" directory. Run 'mvn -U clean install' That should redownload it. . . .

i have added this fix to the bottom of the Troubleshooting section of the wiki page. please read the instructions to see if they are correct. http://www.slightlymagic.net/wiki/Forge:How_to_Get_Started_Developing_Forge#Troubleshooting

[jendave]

invalid LOC header (bad signature) . . .
Sounds like you have a corrupt miglayout jar.

try removing the "C:\Users\jeff\.m2\repository\com\miglayout" directory. Run 'mvn -U clean install' That should redownload it. . . .

i have added this fix to the bottom of the Troubleshooting section of the wiki page. please read the instructions to see if they are correct. http://www.slightlymagic.net/wiki/Forge:How_to_Get_Started_Developing_Forge#Troubleshooting

Looks good. Thanks!

[Braids]

. . . i have added this fix to the bottom of the Troubleshooting section of the wiki page. please read the instructions to see if they are correct. http://www.slightlymagic.net/wiki/Forge:How_to_Get_Started_Developing_Forge#Troubleshooting

Looks good. Thanks!

you're welcome, and thank you for checking them.

transitive thanks also go to Chris H., who reminded me that this should probably go into the document.

[Braids]

Automatic merge occurs when you pull on a branch that is a tracking branch and has commits that diverged the history.

unfortunately, this is not the case with the current version of EGit. i don't know what happened or what exactly is wrong, but if there is only a single conflicting file between the local repository and the remote, both Pull and Merge fail with less than helpful error messages. Team Synchronization is no help; in fact, it tends to perform partial pulls, which get even more confusing. (that's how i learned that hard resets can vaporize local commits. scary.)

the only way i found to force EGit to do the right thing was to use rebase. however, my directions cause this rebase to rewrite local commits, not the remote ones. the instructions are at http://www.slightlymagic.net/wiki/Forge:How_to_Get_Started_Developing_Forge#My_Pull_Failed , if you care to review them. they're very short.

the following was the result of a successful rebase involving divergent changes to CHANGES.txt: https://www.gitorious.org/cardforge/cardforge/commit/e335ef812ba326f66fbe337e5773ef8d95364ca5

[jendave]

Rob,

I think the slightlymagic svn repo will be ready by tomorrow morning. The upload is happening now and it will take many hours. I will also have to manually resolve a lot of commits . Once it is fully up, I'll modify the the pom.xml to be able to do releases, snapshots and the reports/site. I will want to move as quickly as possible off of gitorious because each new checkin over there is a bit of work for me.

[Rob Cashwalker]

Dave, shouldn't we lock down the gitorious repo? Or is it still a matter of testing slightlymagic beforehand?

edit - just for kicks, I pulled the SVN repo from here, and it is going a lot faster than google ever did.. so much for cloud computing...

[Braids]

Rob,

I think the slightlymagic svn repo will be ready by tomorrow morning. The upload is happening now and it will take many hours. I will also have to manually resolve a lot of commits . Once it is fully up, I'll modify the the pom.xml to be able to do releases, snapshots and the reports/site. I will want to move as quickly as possible off of gitorious because each new checkin over there is a bit of work for me.

`
so, this has gone from "let's see how an SVN repository in Germany goes" to "let's ditch gitorious as fast as possible?"

[jendave]

Dave, shouldn't we lock down the gitorious repo? Or is it still a matter of testing slightlymagic beforehand?

edit - just for kicks, I pulled the SVN repo from here, and it is going a lot faster than google ever did.. so much for cloud computing...

I am still cautious about the performance. The current upload is going *very* slowly. It has been running about 12 hours and it is only 5500 revisions in (out of ~11000).

I will then perform the manual conflict resolutions, then we can determine our direction on svn or git. Then I can do a final pull from git into SVN if SVN is indeed what we choose.

[Braids]

i think we can resolve a lot of our git issues by using something other than EGit for pulls and merges. eclipse could then be refreshed, and its EGit integration will understand what happened.

i'll hunt for a gui git mac client. there is an official one for linux and windows.

[jendave]

i think we can resolve a lot of our git issues by using something other than EGit for pulls and merges. eclipse could then be refreshed, and its EGit integration will understand what happened.

i'll hunt for a gui git mac client. there is an official one for linux and windows.

I sometimes use GitX and GitBox as my Gui clients.

[Braids]

SmartGit is available for Windows, Mac, and Linux. it is free for non-commercial use. and it's made in Germany. talk about coincidence.

it is a little difficult to install, but i documented the windows installation. it works with EGit for the most part. it handles Pull conflicts well. it prefers to be the push mechanism as well. as long as you remember to refresh your Eclipse project after working with SmartGit, things seem just fine.

best part is, because it is multi platform, we only have to write one set of instructions. ok, there are deviations in some places.

[Braids]

i've written a guide in the wiki on using SmartGit: http://www.slightlymagic.net/wiki/Forge:_How_to_Install_and_Use_SmartGit

it's a first draft. if we go with git, i would like to take the time to incorporate it into our main development guide.


on another note, i posted to the EGit forum about the errors i was getting when i tried to merge. i even made a second post explaining more of the situation. i haven't gotten any useful responses yet. http://www.eclipse.org/forums/index.php/f/48/