git svn with non-standard svn layout

git svn with non-standard svn layout

[Fabian Molder]

Hello,

- want to use git inside an huge SVN project
 --> so git-svn could do the job ..


- I struggle with two things:
   A) - the SVN project has an non-standard layout
   B) - want to have (several) git's for just the (few) peaces I work on

for A)
======
- svn layout looks like this (simplified):
  - trunk  (not really used, all interesting work in branches)
  - branches
    - r1.2
     - development
     - integration
    - r1.3
     - development
     - integration
    ...

- inside development and integration is:
       - xapplication1
       - xapplication2
       - xapplication3
       ...
       - aa
        -bb
         -cc
          - zapplication1
          - zapplication2
          - zapplication3
          ...

- I created an simplified svn test (from scratch; import/repo/workdir) 
  via this bash-script:   http://pastebin.ca/1608231

for B)
======
- the svn repo is very huge, but I'm only interested in these dirs:
         xapplication2/
         aa/bb/cc/zapplication1
- my objectives: 
   - have several local git's, just the ones I need:
     --> xapplication2/.git
     --> aa/bb/cc/zapplication1/.git


I tried to use "git config svn-remote.svn.branches" to do this,
 please see in function "do_git_svn" in bash-script - but no success

any hints appreciated 

regards,
Fabian

Re: git svn with non-standard svn layout

[Eric Wong]

Fabian Molder <fm122@arcor.de> wrote:
> Hello,
> 
> - want to use git inside an huge SVN project
>  --> so git-svn could do the job ..
> 
> 
> - I struggle with two things:
>    A) - the SVN project has an non-standard layout
>    B) - want to have (several) git's for just the (few) peaces I work on
> 
> for A)
> ======
> - svn layout looks like this (simplified):
>   - trunk  (not really used, all interesting work in branches)
>   - branches
>     - r1.2
>      - development
>      - integration
>     - r1.3
>      - development
>      - integration
>     ...
> 
> - inside development and integration is:
>        - xapplication1
>        - xapplication2
>        - xapplication3
>        ...
>        - aa
>         -bb
>          -cc
>           - zapplication1
>           - zapplication2
>           - zapplication3
>           ...
> 
> - I created an simplified svn test (from scratch; import/repo/workdir) 
>   via this bash-script:   http://pastebin.ca/1608231
> 
> for B)
> ======
> - the svn repo is very huge, but I'm only interested in these dirs:
>          xapplication2/
>          aa/bb/cc/zapplication1
> - my objectives: 
>    - have several local git's, just the ones I need:
>      --> xapplication2/.git
>      --> aa/bb/cc/zapplication1/.git

Hi Fabian,

Since you don't want to track the entire repo and these seem like
unrelated (history-wise) trees, you probably want the simplest cases:

  git svn clone svn://example.com/path/to/xapplication2
  git svn clone svn://example.com/path/to/aa/bb/cc/xapplication1

These commands are like doing the following with plain old svn:

  svn co svn://example.com/path/to/xapplication2
  svn co svn://example.com/path/to/aa/bb/cc/xapplication1

> I tried to use "git config svn-remote.svn.branches" to do this,
>  please see in function "do_git_svn" in bash-script - but no success

svn-remote.svn.branches and tags are really only for repos with
standard layouts.

-- 
Eric Wong

Re: git svn with non-standard svn layout

[Fabian Molder]

Eric Wong <normalperson <at> yhbt.net> writes:

...
> 
> Hi Fabian,
> 
> Since you don't want to track the entire repo and these seem like
> unrelated (history-wise) trees, you probably want the simplest cases:
> 
>   git svn clone svn://example.com/path/to/xapplication2
>   git svn clone svn://example.com/path/to/aa/bb/cc/xapplication1
> 
> These commands are like doing the following with plain old svn:
> 
>   svn co svn://example.com/path/to/xapplication2
>   svn co svn://example.com/path/to/aa/bb/cc/xapplication1
> 
> > I tried to use "git config svn-remote.svn.branches" to do this,
> >  please see in function "do_git_svn" in bash-script - but no success
> 
> svn-remote.svn.branches and tags are really only for repos with
> standard layouts.
> 

Hello Eric,
  hmm, understand,
  but this just does an checkout to the working dir

  the reason for using git is:
    - work offline, with (at least read) access to all the svn branches
    - have some more (privat, not commit back to svn) branches for experiments
    - all the nice git stuff ..
regards,
Fabian

Re: git svn with non-standard svn layout

[Eric Wong]

Fabian Molder <fm122@arcor.de> wrote:
> Eric Wong <normalperson <at> yhbt.net> writes:
> > Hi Fabian,
> > 
> > Since you don't want to track the entire repo and these seem like
> > unrelated (history-wise) trees, you probably want the simplest cases:
> > 
> >   git svn clone svn://example.com/path/to/xapplication2
> >   git svn clone svn://example.com/path/to/aa/bb/cc/xapplication1
> > 
> > These commands are like doing the following with plain old svn:
> > 
> >   svn co svn://example.com/path/to/xapplication2
> >   svn co svn://example.com/path/to/aa/bb/cc/xapplication1
> > 
> > > I tried to use "git config svn-remote.svn.branches" to do this,
> > >  please see in function "do_git_svn" in bash-script - but no success
> > 
> > svn-remote.svn.branches and tags are really only for repos with
> > standard layouts.
> > 
> 
> Hello Eric,
>   hmm, understand,
>   but this just does an checkout to the working dir
> 
>   the reason for using git is:
>     - work offline, with (at least read) access to all the svn branches
>     - have some more (privat, not commit back to svn) branches for experiments
>     - all the nice git stuff ..

Sorry, not sure if I understood you the first time.  The pastie was
hard to read on my screen (big fonts, low res).

I think what you need is to match the number of globs (*) on
both the remote and local sides:

  REMOTE=branches/*/*/aa/bb/cc/zapplication1
  LOCAL=refs/remotes/svn/aa/bb/cc/zapplication1/*/*
  git config svn-remote.svn.branches "${REMOTE}:${LOCAL}"

  #---> matches all in svn repo and also creates subdirs
#
#  git config svn-remote.svn.branches \
#  "branches/r*/development/aa/bb/cc/zapplication1:refs/remotes/svn/branches/*"
#
  #--> Missing trailing '/' on left side of: 'branches/r*/development/aa/bb/cc/zapplication1' (branches/r)

The glob code is still a bit wonky, but it needs to be "/*/" (that is
"*" must have a "/" or nothing, but not "/r*/"

But it looks like the example with 2 globs works.

-- 
Eric Wong

Fwd: git svn with non-standard svn layout

[Chris Harris]

I am using  git version 1.7.6.4 built from the latest stable source on
github.   Running Ubuntu with kernel 2.6.38-11-generic

I can't seem to git git svn to see my branches correctly.
Unfortunately my svn repository is not open source, so I can not post
it here, but I will try to explain my issue.
We use a non standard svn layout like the following
branches
        V4.1
                V4.1.0
                V4.1.1
dev


dev is our trunk, and our branches have 2 levels.
I first use git init, then setup my config as follows
[svn-remote "svn"]
url = file:///home/chris/svnrepo
fetch = dev:refs/remotes/trunk
branches = branches/V4.1/{V4.1.1}:refs/remotes/branches/*
For this example I am just trying to make a single branch work.
After a fetch all revisions are ok. master correctly points to
remotes/trunk,but gitk shows the following:

o remotes/branches/V4.1.1
|
o some commit
|
|
|    o master - remotes/trunk
|    |
|    o another commit
|    /
|
etc
( sorry for the bad ascii art. )
My issue is that trunk ( master ) appears to be a  branch from V4.1.1
instead of  V4.1.1 being a branch from trunk ( master )
git log --graph shows the same structure.
Any suggestions on how to configure this so git svn maps my
non-standard layout correctly?
Thank you
Chris

Re: git svn with non-standard svn layout

[Phil Hord]

On Sat, Sep 24, 2011 at 2:37 PM, Chris Harris <chris.harris123@gmail.com> wrote:
> I am using  git version 1.7.6.4 built from the latest stable source on
> github.   Running Ubuntu with kernel 2.6.38-11-generic
>
> I can't seem to git git svn to see my branches correctly.
> Unfortunately my svn repository is not open source, so I can not post
> it here, but I will try to explain my issue.
> We use a non standard svn layout like the following
> branches
>         V4.1
>                 V4.1.0
>                 V4.1.1
> dev
>
>
> dev is our trunk, and our branches have 2 levels.
> I first use git init, then setup my config as follows
> [svn-remote "svn"]
> url = file:///home/chris/svnrepo
> fetch = dev:refs/remotes/trunk
> branches = branches/V4.1/{V4.1.1}:refs/remotes/branches/*
> For this example I am just trying to make a single branch work.
> After a fetch all revisions are ok. master correctly points to
> remotes/trunk,but gitk shows the following:
>
> o remotes/branches/V4.1.1
> |
> o some commit
> |
> |
> |    o master - remotes/trunk
> |    |
> |    o another commit
> |    /
> |
> etc
> ( sorry for the bad ascii art. )
> My issue is that trunk ( master ) appears to be a  branch from V4.1.1
> instead of  V4.1.1 being a branch from trunk ( master )

In git's estimation,  there is no difference between these two cases.
Visually you may think there is a difference, but graphically (in the
"network graph" sense of the word) they are exactly the same thing.

Consider this history:
o---o---A---B---C <== trunk
         \
          D---E---F  <== V4.1.1

Compare it to this "other" history:
          B---C <== trunk
         /
o---o---A---D---E---F  <== V4.1.1

You might say the first one looks "right" and the second one looks
"wrong".  But in fact, they are the same graph.  They both say that
B's parent is A and D's parent is A.  B and D share a common ancestor
at A.

Here's another view:
          B---C <== trunk
         /
o---o---A
         \
          D---E---F  <== V4.1.1

You may want to read this nice description of the DAG:
http://eagain.net/articles/git-for-computer-scientists/

> git log --graph shows the same structure.
> Any suggestions on how to configure this so git svn maps my
> non-standard layout correctly?

Try git log --graph --date-order to see a slightly different take on things.

Phil