does dmca push us further toward distributed rev control?

[Braids]

thanks, Goblin Hero. i can only speak for myself. i really do appreciate the offer. we may have to accept it one day. i have had some recent problems with git. but each time i use it i am reminded of how fast it is. my suspicion is that we'll keep with gitorious for now. if gitorious gets a "cease and desist" legal order, we will be looking for a new home.

first, we get strikethrough support, and now an offer for a subversion repository? thanks again. you have been very kind most awesome.

[Rob Cashwalker]

I PM'd Goblin Hero, because I can't view that section. I don't think we should stick to git if we don't have to. The eclipse SVN integration is much easier for new devs to figure out.

edit - Just got access. I know that Dave was able to transfer from SVN to Git, including history. Can the same be said about moving back to SVN? Would our SVN history + Git history be transferable?

[jendave]

I PM'd Goblin Hero, because I can't view that section. I don't think we should stick to git if we don't have to. The eclipse SVN integration is much easier for new devs to figure out.

edit - Just got access. I know that Dave was able to transfer from SVN to Git, including history. Can the same be said about moving back to SVN? Would our SVN history + Git history be transferable?

Oh well. I agree with Braids in that Git is much faster. Also, it is great when you use multiple local branches. I usually have a tracking branch that is a copy of the remote and I use a branch of that for longer term changes. It works much better than SVN. Also 'git rebase' and 'git stash' make life much easier.

In any case, if we really want to move back
http://sandrotosi.blogspot.com/2010/02/migrate-git-repo-to-svn-one.html

I'll do it if need be.

[friarsol]

I'd prefer not moving back, at least immediately. I think there's been a bit too much turmoil in the codebase lately, and we'd be better off letting it settle down and let people get accustomed to the new thing. If there's still a lot of hate for git in a month or so, maybe we can move back to SVN somewhere.

[Rob Cashwalker]

I don't think the majority of devs are doing local branches like that... much less using the command line.

I kept a single SVN copy, kept it mostly up-to-date through some big changes, while other times, I just left it alone, then merged a few conflicts after I got the functionality to work. Worked great... I could pull the latest stuff without making sure what I was working on was finshed. (With git we need to commit our local changes before pulling)

Even Braids had trouble dealing with a Git push and she's the OP, in favor of Git..

I see git is used by many dev teams.. but my experience with it for just this small project has not been stellar.

The DMCA issue should just push us away from Google... it shouldn't necessarily push us toward Git, as we could've done that on Google. I feel we settled on gitorious for convenience.. and because it's free. Had Goblin Hero mentioned the SVN offer back on page 1 or 2, would we not have taken it right then and there?

[jendave]

I don't think the majority of devs are doing local branches like that... much less using the command line.

True. I do all of my git and maven work via the command line so I am in the minority here.

The DMCA issue should just push us away from Google... it shouldn't necessarily push us toward Git, as we could've done that on Google. I feel we settled on gitorious for convenience.. and because it's free. Had Goblin Hero mentioned the SVN offer back on page 1 or 2, would we not have taken it right then and there?

Probably. I am concerned about speed however. Git is much faster. Since I do lots of fresh code checkouts to do builds, this is a concern. Again however, I may be in the minority on this.

[Braids]

(With git we need to commit our local changes before pulling)

actually, i recently found this not to be true. the changes should be added before pulling. after that, they can be reset to un-add them without losing changes. i'll update the how to.

I see git is used by many dev teams.. but my experience with it for just this small project has not been stellar.

The DMCA issue should just push us away from Google... it shouldn't necessarily push us toward Git, as we could've done that on Google. I feel we settled on gitorious for convenience.. and because it's free. Had Goblin Hero mentioned the SVN offer back on page 1 or 2, would we not have taken it right then and there?

because git is completely distributed, it would be trivial for us to pop up a new central repository with all history.

for those of us in the western hemisphere, let's consider the svn performance to google. . . and then think about moving that svn repository halfway around the world.

[Rob Cashwalker]

I just got my local copy all screwed up again because I had conflicts after pulling from the main repo. The main conflict I had was that I added a bunch of dependencies in maven for Mantis to work, but meanwhile the pom.xml file had a dozen different revisions since I had last pulled down.

At least with SVN, the merging function would let me choose to accept the incoming version of a file, then I could re-edit that file to include my changes. Now, I had to copy my changed files, (only three java files) then pull a whole new copy, then delete my maven cache because of some plugin it couldn't resolve, and now I'll do what I always did, re-edit the files that I need.

[Braids]

have you tried the merging feature of EGit?

[Rob Cashwalker]

Tried some of that... but its too different. Can't figure out what parts I changed.

if there was just some easy way to reverse the failed pull... revert commit doesn't seem to do anything.

Edit - I just pushed the revision which provides the mantis integration.

[Snacko]

Right click Team Reset, select Hard, select references HEAD. This removes all your changes and checkouts the most recent copy of your branch.
You don't ever ever ever (and many more times) have to reclone the repository to fix anything.

[Rob Cashwalker]

I didn't know what the reset option did, I knew i shouldn't rebase. When would the soft and mixed options be used?

[Snacko]

soft reset -> keeps your index (cache: staged files aka git add, unmerged/confict files) and working copy (all the files you have) but changes to revision you want
hard reset -> resets index + working copy and changes to revision you want
mixed reset -> resets index but not working copy and changes to revision you want

you don't want to use rebase option unless you 100% know what you're doing, because it can alter history and force everyone to reclone the repository to 'fix it'

[Rob Cashwalker]

Thanks snacko, that helps a bit.

[Braids]

soft reset -> keeps your index (cache: staged files aka git add, unmerged/confict files) and working copy (all the files you have) but changes to revision you want
hard reset -> resets index + working copy and changes to revision you want
mixed reset -> resets index but not working copy and changes to revision you want

you don't want to use rebase option unless you 100% know what you're doing, because it can alter history and force everyone to reclone the repository to 'fix it'

soft reset sounds really safe to use. we haven't been using Add much until lately, mostly we've gone from dirty (modified but not added) to committed.

@Snacko, i have a couple of questions.

• under what conditions should we use Merge or Team Synchronize instead of Pull?
• what triggers git to automatically perform merges? Pull into repository with added files? Pull into repository with committed files?

edit: changed "mixed reset" to "soft reset" in first sentence.