Re: Is there any way to add a new directory between already existing directory structure IN CVS.

[Paul Sander]

On Sep 17, 2007, at 8:22 AM, Dennis Jones wrote:

> <address@hidden> wrote in message
> news:address@hidden
> > Is there any way to add a new directory between already existing
> > directory structure IN CVS .
> > Like I have directory structure "MyRepository/ConfigFile/origional"
> > etc. Now i want to add one more directory between "ConfigFile and
> > origional " say newDir so that my new directory structure should be
> > "MyRepository/ConfigFile/newDir/origional "
>
> CVS does not perform revision control on directories, so if you have 
> direct
> access to the repository files on the server, then you can do that by 
> simply
> moving the directores around.  However, be aware that any change you 
> make
> will affect everyone who already has 
> "MyRepository/ConfigFile/origional"
> checked out, who will very likely have to check out
> "MyRepository/ConfigFile" from scratch after you make the change.  
> Also note
> that the history information for files in the "origional" folder (and 
> its
> descendants) will have no record of the change.  Finally, if you have 
> any
> scripts, build tools, or anything that depends on the existing 
> directory
> structure, you will be unable to go back and use earlier revisions.  
> So, in
> other words, be very careful, and only do it if none of these cautions 
> I've
> mentioned will be an issue (such as a brand new repository for 
> example).
>
> As an alternative, you could just add "NewDir/origional", and then add 
> the
> contents of the "ConfigFile/origional" folder to "NewDir/origional" 
> folder,
> and then remove the contents of the original "origional" folder.  That 
> would
> preserve the history, and would allow you to check out an earlier 
> revision
> if you ever needed it.
>
> Does that help?
>
> - Dennis

There are also tricks that you can play with the modules database to 
remap repository directories to their counterparts in the users' 
workspaces.  However, because only the latest version of the modules 
database is ever used, you must version such modules by way of naming 
conventions and keep all of the mappings currently in use in the latest 
version.

Also, this method doesn't scale.  The clutter, both in the database and 
in the repository, becomes unmanageable after a very few such mappings 
are added.  However, it works when such reorganizations are very rare, 
they have wide impact, and the normal fracturing of version history 
just won't do.

--
Paul Sander       | "Lets stick to the new mistakes and get rid of the 
old
address@hidden | ones" -- William Brown