moving org under src

[James Tauber <jt...@jtauber.com>]

I'm hoping to

(a) move the org directory under src (and presumably codegen, the makefiles
and overview.html too)
(b) change org.apache.xml.fop to just org.apache.fop for consistency with
the other Apache projects

Any way of doing this without having to do an add and rm for every single
file? I'll do that if I have to but if anyone is around at the moment, I'd
sure appreciate any tips people have! :-)

James

Re: moving org under src

[Dirk-Willem van Gulik <di...@webweaving.org>]

Ok.. make sure you let the world know when you are done.. and what
we have to do to get in sync again :-) But you are right, this
is the right time to do this drastic stuff.

DW

On Tue, 16 Nov 1999, James Tauber wrote:

> > Well.. see the 'FAQ' :-)
> 
> Yes, I did that *after* I sent my post and *before* I read yours :-)
> 
> > the easiest way is to log onto taz and simply do
> > a 'mv' in the repository. And then _warn_ everyone that this has
> > happeneded as well all have to re-checkout our repos's.
> 
> That's what I'm doing right now.
> 
> James
> 
> 

Re: moving org under src

[James Tauber <jt...@jtauber.com>]

> Well.. see the 'FAQ' :-)

Yes, I did that *after* I sent my post and *before* I read yours :-)

> the easiest way is to log onto taz and simply do
> a 'mv' in the repository. And then _warn_ everyone that this has
> happeneded as well all have to re-checkout our repos's.

That's what I'm doing right now.

James

Re: moving org under src

[Dirk-Willem van Gulik <di...@webweaving.org>]

On Tue, 16 Nov 1999, James Tauber wrote:

> Any way of doing this without having to do an add and rm for every single
> file? I'll do that if I have to but if anyone is around at the moment, I'd
> sure appreciate any tips people have! :-)

Well.. see the 'FAQ' :-) the easiest way is to log onto taz and simply do
a 'mv' in the repository. And then _warn_ everyone that this has
happeneded as well all have to re-checkout our repos's.

See http://wuarchive.wustl.edu/systems/gnu/Manuals/cvs-1.9/html_mono/cvs.html#SEC71
for example.

I am willing to do it for you if you let me know the exact details.

Dw

**** Moving and renaming directories

If you want to be able to retrieve old versions of the module, you must
move each file in the directory with the CVS commands. See section The
Normal way to
Rename. The old, empty directory will remain inside the repository, but it
will not appear in your workspace when you check out the module in the
future. 

If you really want to rename or delete a directory, you can do it like
this: 

    1.Inform everyone who has a copy of the module that the directory will
be renamed. They should commit all their changes, and remove their working
copies of
       the module, before you take the steps below. 
    2.Rename the directory inside the repository. 

       $ cd $CVSROOT/module
       $ mv old-dir new-dir

    3.Fix the CVS administrative files, if necessary (for instance if you
renamed an entire module). 
    4.Tell everyone that they can check out the module and continue
working. 

If someone had a working copy of the module the CVS commands will cease to
work for him, until he removes the directory that disappeared inside the
repository. 

It is almost always better to move the files in the directory instead of
moving the directory. If you move the directory you are unlikely to be
able to retrieve old
releases correctly, since they probably depend on the name of the
directories. 

**** Moving and renaming files

Moving files to a different directory or renaming them is not difficult,
but some of the ways in which this works may be non-obvious. (Moving or
renaming a
directory is even harder. See section Moving and renaming directories). 

The examples below assume that the file old is renamed to new. 

The Normal way to Rename

The normal way to move a file is to copy old to new, and then issue the
normal CVS commands to remove old from the repository, and add new to it.
(Both old and
new could contain relative paths, for example `foo/bar.c'). 

$ mv old new
$ cvs remove old
$ cvs add new 
$ cvs commit -m "Renamed old to new" old new

This is the simplest way to move a file, it is not error-prone, and it
preserves the history of what was done. Note that to access the history of
the file you must
specify the old or the new name, depending on what portion of the history
you are accessing. For example, cvs log old will give the log up until the
time of the
rename. 

When new is committed its revision numbers will start at 1.0 again, so if
that bothers you, use the `-r rev' option to commit (see section commit
options) 

Moving the history file

This method is more dangerous, since it involves moving files inside the
repository. Read this entire section before trying it out! 

$ cd $CVSROOT/module
$ mv old,v new,v

Advantages: 

       The log of changes is maintained intact. 
       The revision numbers are not affected. 

Disadvantages: 

       Old releases of the module cannot easily be fetched from the
repository. (The file will show up as new even in revisions from the time
before it was
       renamed). 
       There is no log information of when the file was renamed. 
       Nasty things might happen if someone accesses the history file
while you are moving it. Make sure no one else runs any of the CVS
commands while you
       move it. 

Copying the history file

This way also involves direct modifications to the repository. It is safe,
but not without drawbacks. 

# Copy the RCS file inside the repository
$ cd $CVSROOT/module
$ cp old,v new,v
# Remove the old file
$ cd ~/module
$ rm old
$ cvs remove old
$ cvs commit old
# Remove all tags from new
$ cvs update new
$ cvs log new             # Remember the non-branch tag names
$ cvs tag -d tag1 new
$ cvs tag -d tag2 new
...

By removing the tags you will be able to check out old revisions of the
module. 

Advantages: 

       Checking out old revisions works correctly, as long as you use
`-rtag' and not `-Ddate' to retrieve the revisions. 
       The log of changes is maintained intact. 
       The revision numbers are not affected. 

Disadvantages: 

       You cannot easily see the history of the file across the rename. 
       Unless you use the `-r rev' (see section commit options) flag when
new is committed its revision numbers will start at 1.0 again.