On Thu, Apr 3, 2008 at 2:40 PM, Dan Stromberg <dstromberglists_at_gmail.com>
wrote:
> Hari Kodungallur wrote:
>
>
> > On Thu, Apr 3, 2008 at 2:02 PM, Dan Stromberg <dstromberglists_at_gmail.com<mailto:
> > dstromberglists_at_gmail.com>> wrote:
> >
> >
> > If I run a basic "svn log" command like:
> >
> > $ svn log http://eng2/svn/Datallegro/branches/v3.1.4-dev | wc -l
> > 128
> >
> > ...as you can see, I get a tiny number of lines - but there should
> > be thousands if svn is going back to the beginning of repository
> > history as I keep hearing it's supposed to. And we could really
> > use complete history.
> >
> > I get that same short result whether using an svn 1.1.4 client on
> > CentOS 4.6, or an svn 1.4.4 client on openSUSE 10.3. In both
> > cases, the clients are talking to an svn 1.1.4 server via WebDAV
> > with FSFS backends on CentOS 4.6.
> >
> > I know, 1.1.4 is really old. I doubt my management is going to go
> > for an upgrade without a really good reason though. Is there much
> > chance that upgrading the subversion (and 3 repositories) on our
> > server to 1.4.6 would help "svn log" go back to the beginning of
> > time like it should? Or would it at least fix new commits?
> >
> > Thanks!
> >
> >
> >
> > The default behaviour of svn is traverse the history of the branch when
> > doing svn log. So you should have got all the history until the beginning of
> > time. Please look at the entire content of the 'svn log' and see where it
> > stops.
> >
> > Did you create the branch using the 'svn copy' command? Or was it
> > populated from a local copy of source code or something like that? I know
> > that sounds like something no one would do; but I can not imagine a scenario
> > where svn will not print the whole history of a branch. Basically if you do
> > "svn log -v URL --stop-on-copy" and then look at the very last printed
> > revision, you will be able to tell how the branch was created?
> >
> >
> > Regards,
> > -Hari
> >
> I'm afraid we are probably checking out, changing and checking in, like
> you said no one would do :)
>
> This is kind of interesting:
>
> $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev
> --stop-on-copy | wc -l
> 199
> eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above cmd
> done 2008 Thu Apr 03 02:24 PM
>
> $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev | wc -l
> 199
> eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above cmd
> done 2008 Thu Apr 03 02:24 PM
>
> It seems to stop at the same place --stop-on-copy does.
>
> The way we create new branches is to:
> 1) "svn checkout" the source branch nonrecursively - this doesn't really
> check out much
> 2) modify the external references at the top level
> 3) do an "svn update" to get the rest of the code - this checks out a lot
> 4) modify a few remaining externals
> 5) "svn update" again
> 6) "svn switch" to name the checked out code to something new
> 7) "svn commit"
>
> Is that appropriate? I don't have a huge amount of SCM experience, and
> inherited most of this process.
>
> I suspect we may be doing it this way because our trunk is scattered all
> over, but we have a single subversion directory with external references
> that unifies the pieces.
>
> Is the alternative to do one "svn copy" for every external reference?
>
>
I am afraid this is not the best way to create the branches. 'svn switch'
will completely switch (move) your branch to a new location in the
repository. And when you do this (a) it will remove your old branch and (b)
it will leave no trace of history for the new branch.
My suggestion will be to do the following (if you can make it a script, it
will be better).
- 'svn copy' your tree to a branch directory
- separately checkout -N (non-recursive) each directory within the new
branch where the externals have to be set.
- update the externals for each of these directories and check-in each
directory
Hope this helps,
rgds,
-Hari
Received on 2008-04-04 00:21:47 CEST