[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: File movement operations...

From: Ryan Schmidt <subversion-2008c_at_ryandesign.com>
Date: Sat, 27 Sep 2008 02:26:25 -0500

On Sep 22, 2008, at 10:04, BRM wrote:

> I have a repository that I converted from CVS:
>
> cvs export X
> svn co Y
> copy X into Y
> svn add *
> svn commit
>
> I now need to re-organize a number of files into new folders, etc.
> However, it is a working repository that several developers use,
> and there are a lot of projects within it. There is also a nightly
> build.
>
> Eventually I will be moving each project into its own project space
> in the repository; but before I can do that, I need to move the
> commonly shared code into its own project. I'd like to try to do it
> with as little breakage as possible when I check things back-in.
>
> I've been using subversion for several years, and am aware that SVN
> is quite smart in many ways. However, is it smart enough for what I
> want to do (below)?
>
> I'm considering two approaches:
>
> 1) Move files around within the current revision, modify the
> projects to build using the new file locations, and then check-in.
> 2) Branch, do the #1 on the branch instead, then merge everything
> back.
>
> I would normally do major changes on a branch (#2), but am
> concerned as I don't want to lose any updates to existing files -
> i.e. if I move a file, and then do 'svn update', will it carry
> updates to the file to the new file location? (I think it will, but
> want to make sure.) And will another developer's workspace carry
> their working changes over (if they have any)? Is the merging
> smart enough to carry over changes when merging trunk back into the
> branch (updating the branch) before merging the branch back to
> trunk (to close out the branch)?

I recommend you don't do this on a branch. Do it on the trunk, at a
time when nobody has any outstanding changes in the affected areas.
Subversion is not smart in this situation and will not make it easy
for your developers if they have uncommitted changes in parts of the
tree that you rename.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-27 09:26:52 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.