Re: Moving a repository with svn:externals using absolute paths (URLs)
On 19.06.2014 05:11, Geoff Field wrote: >> From: Nico Kadel-Garcia >> On Wed, Jun 18, 2014 at 9:35 PM, Geoff Field wrote: >> >>> In our duplication effort, we also set all the permissions >>> on the old repositories to read-only, to limit the chances >>> of cross-contamination. > Just to be clear, I'm not talking about the FILE permissions > here, merely the SVN access permissions. To be really clear, > the original repositories are only being kept as a paranoia > measure, just in case our customers (or legal representatives) > require unsullied history at some indefinite time in the future. > >>> Regards, >>> >>> Geoff >> This. So much this. When people want to keep, and keep >> cross-merging, the contents of multiple distinct live >> repositories while work is being replicated and cross-merged >> from all of them, it's usually time to look for a new job: > The vast majority of those repositories have been unused for > some years, and our development team is (now) small enough so > that I can guarantee there was no work proceeding on any of > them. Naturally, I also shut down SubVersion while it was in > progress, just in case. > >> someone has been excited by the shiny tools and forgotten > Ooh, shiny ... What were we talking about? ;-) > >> "source control is a 24x7, it must *work* and work *every >> time*" resource. > Quite right. That's why our repositories are on a RAID system > (now a SAN, actually) with regular backup (including off-site). Finally some SANity! You'd be surprised at how many SVN admins forget that it's probably *the* best option. :) -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Unexpected behaviour when checking out a copy at an invalid revision
Hi Stefan, Thanks for the explanation - I always forget about the subtleties of using -r versus @. I now understand what Subversion is doing here and why, but I maintain that it should give some indication that the workspace is not pointing at the "expected" repository location. Yes, it's the result of user error (or may even be intentional), but an info or warning would be helpful. All the best, fergus On 05/27/2014 02:46 AM, Stefan Sperling wrote: On Sun, May 11, 2014 at 07:10:47PM +1200, Fergus Slorach wrote: Checking out a copied directory at a revision prior to the copy results in a checkout of the data before the copy. I would expect this to fail in the same way that attempting to update to an invalid revision fails. Is this the intended behaviour? Hi Fergus, Yes, it is. 'svn checkout -rX URL' is says: Please give me the content of URL as it appeared in rX, following copy history if necessary. If so, shouldn't there be some message that your working copy is using a different location than requested? Try: svn checkout URL@X This says: Please locate URL in revision X and give me its content. This will fail if URL doesn't actually exist in rX. This matches the behaviour you expected from checkout -rX, doesn't it? Subversion expects you to specify a peg revision if you want something from a specific revision. See this page: http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html Note that the command you gave has an implicit peg revision of HEAD (HEAD being the youngest revision in the repository): svn co -r X URL@HEAD svn copy trunk mybranch -m 'copy test' Committed revision 2 svn co mybranch -r1 mybranch svn info mybranch Relative URL: ^trunk Checking out the branch at a valid revision then attempting to update to the earlier revision results in an error: svn: E160005: Target path 'mybranch' does not exist You need to use 'svn switch' to change the URL of an existing working copy. Again, this is by design. If working copies could be switched to different URLs during 'update', users might end up making commits to the wrong branch without realising it. (Admittedly, in your checkout -rX case, this could also happen -- but we can wiggle ourselves out of the resulting conundrum by claiming it is considered an error on behalf of the user because a peg revision should have been used ;) So what you tripped over is the small semantic difference between an operative revision and a peg revision during 'svn checkout'. This is a common mistake, but Subversion needs to support both cases, and users are required to learn about this difference to make proper use of the system. Does that make sense?
