Re: Preferred doc checkouts

> >>> > >> No, and what is worse svn does not fail, it simply ignores any changes > >> in svn:externals. > >> > >> Unless you only ever plan to change docs in a single translation, I > >> don't recommend using the svn:externals modules. However, for those > >> people who are exclusively documenting in 1 language, and never touch > >> the source code they're documenting it is a great system. > >> > >> For everyone else, use a sparse checkout. I put in a small amount of > >> effort last week to make phd work, and as long as you aren't adding in > >> images, it works fine (phd needs a small change to allow it to find > >> images in a sparse checkout, which I have not and will not investigate > >> since I don't care about images :). > >> > >> Greg > >> > >> > > > > My experience is different. I'm using TortoiseSVN on Windows XP SP3. > > > > I recently made a change to doc-en involving both doc-base and en - > > see > > http://svn.php.net/viewvc?view=revision&revision=286553 > > > > Hi, > > Great - so that means users of TortoiseSVN don't have this issue. The > command-line subversion client is the only deficiency if you're using > svn:externals. Good to know. > Hi, I just made a simple test with my repository and native svn-client Subversion 1.4.4 native svn-client 1.6.3 repository layout: > tmp/test1 > tmp/test2 > tmp/test3 > under tmp/test1 , svn:externals > ext-t2 http://localhost/svn/tmp/test2 > ext-t3 http://localhost/svn/tmp/test3 > So, when I make svn co http://localhost/svn/tmp/test1, the whole thing becomes > /test1 > /test1/ext-t2 > /test1/ext-t3 > Then I touched 3 files. > /test1/t1 > /test1/ext-t2/t2 > /test1/ext-t3/t3 > svn st gives > X ext-t2 > X ext-t3 > ? t1 > > Performing status on external item at 'ext-t2' > ? ext-t2/t2 > > Performing status on external item at 'ext-t3' > ? ext-t3/t3 > after svn add and I perform svn ci -m "test" t1 ext-t2/t2 ext-t3/t3 gives: > Adding t2 > Adding ext-t2/t2 > Adding ext-t3/t3 > Commit with no problem and sharing the same commit log. Thus I think svn:externals gives no problem at all (with native svn-client 1.6.x I think) ks