Interesting (?) trivia regarding svn-import and question about workflow

[Russel Winder]

Jelmer,

I am rather pleased with this one, and cannot resist sharing it with you
-- but there is a more serious question at the end.

I wanted to have a local version of the Kent occam compiler so I could
compile it up for use on all my machines.  It is a Subversion repository
but I don't use Subversion for any project work mainly because of all
the .svn directories.  So I thought use Git:

	M	trunk/runtime/libtvm/ins_t800.c
	M	trunk/runtime/libtvm/tvm_config.h.in
	M	trunk/runtime/libtvm/instructions.h
	M	trunk/runtime/libtvm/tvm_mem.h
	M	trunk/runtime/libtvm/ins_proc.c
Incomplete data: Delta source ended unexpectedly at /usr/lib/git-core/git-svn line 5047

Something in the commit is not manageable with Git.  I have no idea
where to put the bug report.  So I tried Mercurial:

[r4459] cgr: I take that back, ccsp_config.h.in does need to be in the repository, but it also needed some updating.
** unknown exception encountered, details follow
** report bug details to http://mercurial.selenic.com/bts/
** or mercurial at selenic.com
** Mercurial Distributed SCM (version 1.4.3)
** Extensions loaded: rebase, svn
Traceback (most recent call last):
. . . 
AssertionError: kroc/trunk/runtime/ccsp/include/ccsp_config.h.in not found

Looks like the same problem causing the same result as with Git.  I have
posted a bug report with hgsubversion for this.  So now try Bazaar:

|> bzr svn-import http://projects.cs.kent.ac.uk/projects/kroc/svn/kroc KRoC
Initialising Subversion metadata cache in /home/users/russel/.bazaar/svn-cache/ee8ce1bd-81f8-0310-a706-c2403d3965fe.                                
Importing branches with prefix /kroc/                                                                                                               
Using repository layout: trunk1                                                                                                                     
Use 'bzr checkout' to create a working tree in the newly created branches.
|>                                                                     

Rock on dude.

The real question is what are the canonical (!) workflows for using this
tool.  Currently I am thinking that such a shared repository created
using svn-import has to be used as a read-only mirror, but then this
means having to use a second shared repository for the working branches.
Clean separation but double the space required.  Having working branches
in the same repository then means mixing read-only and read-write
activity, but we probably always do this anyway.

I guess the real questions is whether svn-import can safely act as a
pull operation for a shared repository which has branches not present in
the Subversion repository?

Thanks.

PS  If I have just missed a bit of documentation, please do point me at
it.  Thanks. 

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100623/5409c5dc/attachment-0001.pgp