Re: Subversion Copy (copied_from)

Right, That much makes sense for a "move" operation. I can at least live with the idea that renaming the main directory wouldn't affect the subdirectories and files (although since mv is performed as cp/rm it updates the subfolder and subfile revisions so probably should add the copied_from while its at it imo). But... how about if you copy a to z instead (as in a branch operation). Now you have z/b and z/b/c underneath the copied directory (originally all from a). The only problem is, that unlike the main directory z, z/b and z/b/c contain no information about having been copied from a/b and a/b/c respectively (mind you the history will show all the revisions including those from a/* where the files originally came from and revisions prior to the ones existing in z/* will have a different path field). However, the specific revision where they were copied (since as you demonstrated with a move[cp/rm] operation it already creates a history at this revision for every item involved) should contain the copied_from field just like the main directory I would think. This is the behavior I was really questioning, sorry for not being specific enough about it. Hopefully I have made my point clearer. With the specific history having been added for every item involved already I can really see no reason why the copied_from field wouldn't exist and logically it seems it should. P.S. I actually believe that because of the way a mv operation is implemented currently, it should also implement the copied_from field until such time (if ever) a mv operation no longer creates specific history for every sub-item involved in a directory rename. -Q ----- Original Message ---- From: B. Smith-Mannschott <benpsm_at_gmail.com> To: Quentin Narferao <qnarferao_at_yahoo.com> Cc: Subversion Users <users_at_subversion.tigris.org> Sent: Tuesday, January 23, 2007 12:42:24 PM Subject: Re: Subversion Copy (copied_from) On Jan 23, 2007, at 19:16, Quentin Narferao wrote: > I'm not entirely sure if this is a bug but it seems to me that it > might be. > > [repos]/dir1/dir2/file.txt > > where dir1 is copied or moved to: /dirX > and the resulting subdirectories are also copied/moved so that the > new access would be: > [repos]/dirX/dir2/file.txt > > In the repository dirX will return the fact that it was copied > (even if it was moved--that's possibly another bug) This is normal behavior. The move (aka rename) operation is implemented as copy + delete. See also <http://subversion.tigris.org/ issues/show_bug.cgi?id=898> > but everything below (dir2 and file.txt) will not report the fact > that they were copied (or moved) from their original location under > [repos]/dir1. This is according to fs.copied_from API (as seen > through ViewVC and even the TortoiseSVN client show log feature). That's because they have not been moved or copied. The only thing that's happened is that dir1 has been renamed (to dirX). > First of all, is this intended or is this a bug? I cannot see a > reason that the files underneath the primary directory being copied/ > moved would gain a new revision number but not have the copied_from > field present--especially given the fact that the primary directory > that was the argument for the copy/move did receive this field. The revision number applies to the repository as a whole. The revision number next to the entries shown in status is the revision of that item's last modification. alden:/tmp/r bsmith$ svn status --verbose 0 0 ? . 1 1 bsmith a 1 1 bsmith a/b 1 1 bsmith a/b/c alden:/tmp/r bsmith$ svn mv a z A z D a/b/c D a/b D a alden:/tmp/r bsmith$ svn ci -m '' . Deleting a Adding z Committed revision 2. alden:/tmp/r bsmith$ svn status --verbose 0 0 ? . 2 2 bsmith z 2 2 bsmith z/b 2 2 bsmith z/b/c But, you are correct, the rename operation on appears to rewrite the subdirectories too, which is probably a symptom of the way that subversion works internally. Perhaps perusing <http://svnbook.red-bean.com/nightly/en/svn.basic.in- action.html#svn.basic.in-action.wc.dia-1> near Figure 1.7 (section "Revisions") will shed some light. // Ben ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Received on Thu Jan 25 00:30:48 2007