Re: [git-users] git-svn setup advice for newbie

2011-01-02 Thread Konstantin Khomoutov
On Sun, Jan 02, 2011 at 11:39:36PM +, graham wrote:

[...]
>> Hence, the course of action for you would probably be:
>> 1) Prepare the authors file.
>> 2) git-svn clone the Subversion repo.
>> 3) Fork its master branch to your two local branches.
> Is there a best way to do the fork? For longstanding branches I guess a
> cp -r would be better than a git branch?
I don't think so -- Git's switching of branches is light-fast and you only
should consider something like `cp -r` (but *not* exactly this, see below)
only if you for some reason really want to have these two branches
available in parallel as two checkouts (two directories on your hard
drive available both at the same time).
Note that it's possible to switch to another branch while in the middle
of hacking thanks to the `git stash` command -- you `git stash` the
changes in your work tree (and hence make it clean), switch to another
branch, do something on it, switch back, and `git stash pop` the changes
you stashed at the first step.

I think if you really want to have any two branches to be checked out in
parallel, it suggests you'd better have two different repositories for
them.

Also there's no need to use `cp -r` in any case -- if you clone a
repository locally, Git tries to hardlink everything it clones. There
are even methods to explicitly share certain objects.

>> 4) Add another two remotes (the first one will be "svn", created by git-svn)
>>which you will use to do pushes to your staging and production
>>servers.
> I don't follow this step - why does one of the remotes need to be svn,
> not pure git?
Bad phrasing on my part: "the first" is meant to designate the remote
that `git svn init/clone` will create for you -- it is named "svn" by
default. Then you add two other remotes for your Git servers.

[...]

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



Re: [git-users] git-svn setup advice for newbie

2011-01-02 Thread graham
Thanks for the recipe, Konstantin.

The main thing I'm trying to achieve at the moment is to create an
initial setup I can build on, not put a lot of work into a setup I need
to revert out of because I made a mistake in understanding how git(-svn)
works.

On 01/02/11 23:07, Konstantin Khomoutov wrote:

> Hence, the course of action for you would probably be:
> 1) Prepare the authors file.
> 2) git-svn clone the Subversion repo.
> 3) Fork its master branch to your two local branches.

Is there a best way to do the fork? For longstanding branches I guess a
cp -r would be better than a git branch?

> 4) Add another two remotes (the first one will be "svn", created by git-svn)
>which you will use to do pushes to your staging and production
>servers.

I don't follow this step - why does one of the remotes need to be svn,
not pure git?

> 5) When needed, `git svn fetch` the changes from the Subversion repo
>then switch to each of your local branches in turn and do `git rebase
>master` in them.

Fine

> 6) How to push to the staging and production servers is really beyond
>this question as it depends on your requirements and taste.
> 

Sure.

> Having multiple developers working with you *might* require that you
> have only one box which does fetching from the Subversion repo and then
> pushes the resulting changes in the tracking branch to some server, and
> everyone else fetches from there. 

OK, makes sense.

Thanks
Graham

This might be necessary as fetching
> from Subversion *creates* Git commit objects, and this process depends
> on local settings (including the authors file, if used) -- having
> different local settings might result in creation of commits which hash
> to different SHA-1 hashes for the same Subversion revisions, and this
> obviously breaks the idea central to Git of identical objects having
> identical hashes.
> 
> 1. http://wiki.debian.org/Alioth/Git#ConvertaSVNAliothrepositorytoGit
> 

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



Re: [git-users] git-svn setup advice for newbie

2011-01-02 Thread Konstantin Khomoutov
On Sun, Jan 02, 2011 at 08:04:14AM -0800, navtis wrote:

> I'm new to git, and am looking for advice on the best way to create a
> moderately complicated setup with the following constraints:
> 
> * The main public repository for this software is subversion, and is
> not under my control
> * I need to fetch updates from the subversion repository to my
> development host (running gentoo) regularly, but cannot write to it
> (my updates are pushed back through manually created patches)
> * I need to create two branches for my local code, both of which need
> to be regularly merged with the updates from subversion
> * I need to be able to export both branches local code to a staging
> server, which is running centos (the OS is relevant as I expect to
> have to make minor tweaks to the code to get it running with different
> library versions etc)
> * The production server is running RHE, and no development work should
> take place on it. It will only run one of the two branches.
> * I am working on my own at the moment but there are likely to be
> other developers involved soon

I'm not quite sure what exactly you want advice on.
If you only need to periodically fetch from a Subversion repo using
git-svn, that's fine -- you will get a branch which is not really
different from a branch that would result from fetching from a Git repo.
The rest is just usual Git operations which will not be aware of
the fact Subversion is present in this picture.

The only problem I can envision off the top of my head is the need to
maintain the "authors" file to do fetches from Subversion and get
sensible author names and e-mail addresses in the generated Git commits.
See [1] for the hints on how to do this.

Hence, the course of action for you would probably be:
1) Prepare the authors file.
2) git-svn clone the Subversion repo.
3) Fork its master branch to your two local branches.
4) Add another two remotes (the first one will be "svn", created by git-svn)
   which you will use to do pushes to your staging and production
   servers.
5) When needed, `git svn fetch` the changes from the Subversion repo
   then switch to each of your local branches in turn and do `git rebase
   master` in them.
6) How to push to the staging and production servers is really beyond
   this question as it depends on your requirements and taste.

Having multiple developers working with you *might* require that you
have only one box which does fetching from the Subversion repo and then
pushes the resulting changes in the tracking branch to some server, and
everyone else fetches from there. This might be necessary as fetching
from Subversion *creates* Git commit objects, and this process depends
on local settings (including the authors file, if used) -- having
different local settings might result in creation of commits which hash
to different SHA-1 hashes for the same Subversion revisions, and this
obviously breaks the idea central to Git of identical objects having
identical hashes.

1. http://wiki.debian.org/Alioth/Git#ConvertaSVNAliothrepositorytoGit

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



[git-users] git-svn setup advice for newbie

2011-01-02 Thread navtis
Hi,

I'm new to git, and am looking for advice on the best way to create a
moderately complicated setup with the following constraints:

* The main public repository for this software is subversion, and is
not under my control
* I need to fetch updates from the subversion repository to my
development host (running gentoo) regularly, but cannot write to it
(my updates are pushed back through manually created patches)
* I need to create two branches for my local code, both of which need
to be regularly merged with the updates from subversion
* I need to be able to export both branches local code to a staging
server, which is running centos (the OS is relevant as I expect to
have to make minor tweaks to the code to get it running with different
library versions etc)
* The production server is running RHE, and no development work should
take place on it. It will only run one of the two branches.
* I am working on my own at the moment but there are likely to be
other developers involved soon

Having got a bit lost with the wealth of detail in the git and git-svn
documentation, I thought it might be easier to ask for advice!

Thanks in advance

Graham

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.