Patrick Doyle wrote: > Hello all, > I've read http://utsl.gen.nz/talks/git-svn/intro.html, "An > introduction to git-svn for Subversion/SVK users and deserters" and, I > guess I'm looking for a little more information. [...] > svn://host/wpd/{project1,project2,project3}. Since it's my own > personal playground, I don't need branches, and tend to remember tags > just be commit number. There's your first issue - misunderstanding branching :) You should end up realising that every little idea or feature forms a code branch in the direction of its implementation, the choice is whether to let the branches twist and grow together or train them in clear directions. > Here's where I get stuck... > 1) How can I remind myself of what I changed relative to what was in > the Subversion repository the last time I sync'd to it? Under my > current model of operation, I come in after a weekend/night away, do > "svn status" and "svn diff" to remind myself what's changed, and > commit those changes with appropriate log messages. I am hoping that > I can make the changes locally, commiting them with nice log messages > as I make the changes, and then "push" them to the subversion server > when convenient. use git-branch -a to show you the name that the remote subversion branch is set up on. then you can use "git-diff svn/trunk" (say, if it listed it as "svn/trunk") to show you the files changed between your working copy and the last subversion commit you did. I can see that this point isn't very clear from the tutorial if you go straight in at "How to ... commit back to Subversion". That section needs a bit of an overall introduction I think. The idea is that first, you make the changes in your local branch. (see http://utsl.gen.nz/talks/git-svn/intro.html#local-commit). Then you use dcommit to save it to Subversion. Using this you can stage multiple commits, and if you don't like them you can go back and review them before they are set in SVN forever. That mode of operation is already natural for SVK users which the tutorial was primarily targeted at - so they were probably already looking for information on how to create a local branch, make local changes and then push back. > 2) This is going to have some obvious problems when I work on other > projects shared with other developers. We know how to address this > with Subversion (good communication, updating the working copy prior > to a commit, resolving the minor conflicts, etc...) what can I expect > when my local repository is git? If svn is still the master there should be no difference to the way you normally collaborate development using Subversion. The central server is still the publishing point for trunk, however many release engineering branches you use, and feature branches. It's only if you want to start mixing groups of people, some working with subversion, and other people using git-svn and merging between each other at the git level, that you can start getting confused. They can safely operate at the patch trading level though. > 3) If I try to commit my change with: > > $ git-svn dcommit > > I get an error > Commit 0e3e.... > has no parent commit, and therefore nothing to diff against. > You should be working from a repository originally created by git-svn > > and that's where I get confused. Is this a bug/feature of 1.5.0.2 > that will disappear if I switched to 1.5.2.2? > > Are there any other tips/resources for mixed mode operation > (centralized Subversion server, distributed git client(s))? Almost certainly because you haven't committed locally yet. Sam. > > Thanks for any pointers. > > --wpd > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
