Home » Eclipse Projects » Technology Project and PMC » Reorganizing Projects while maintaining history
| Reorganizing Projects while maintaining history [message #64964] |
Tue, 20 July 2004 21:30  |
Eclipse User |
|
|
|
Originally posted by: eclipse.wingspread.imap-mail.com
I don't know if this is the correct newsgroup for this question, if it
isn't please let me know which group would be better.
I'm using Eclipse 3.0 and I have an application which has been built up
over time. Most of the code resides in a single Java project which is
stored in our CVS repository. The project has reached the point where I
would like to move things out into their own project. However, if I
simply move the files from Project A to Project B, the files will all be
'new' in Project B and I will have lost all history associated with the
files. I know there isn't a way to do this from within Eclipse, but is
there a relatively easy way to accomplish this rearrangement from either
the cvs command line level or through careful work within the CVS file
system itself?
It is unfortunate that the version control system in Eclipse doesn't treat
Java files (including the package) or other artifacts as objects which you
could just move around or rename without losing history.
Thanks for any help.
--
James Howe
|
|
|
| Re: Reorganizing Projects while maintaining history [message #64976 is a reply to message #64964] |
Wed, 21 July 2004 14:17  |
| Eclipse User |
|
|
|
Originally posted by: eeide.cs.utah.edu
"James" == James Howe <eclipse@wingspread.imap-mail.com> writes:
James> I'm using Eclipse 3.0 and I have an application which has been
James> built up over time. Most of the code resides in a single Java
James> project which is stored in our CVS repository. The project has
James> reached the point where I would like to move things out into
James> their own project. However, if I simply move the files from
James> Project A to Project B, the files will all be 'new' in Project B
James> and I will have lost all history associated with the files. I
James> know there isn't a way to do this from within Eclipse, but is
James> there a relatively easy way to accomplish this rearrangement
James> from either the cvs command line level or through careful work
James> within the CVS file system itself?
This is a classic problem with CVS, and is addressed in the CVS FAQ:
<http://www.loria.fr/~molli/cvs/cvs-FAQ/cvsfaq8.html#2C.4>
and in various books about CVS, including this one (free!):
<http://cvsbook.red-bean.com/>
But instead of trying to be fancy --- which has its own problems --- many
people just do the "obvious" thing that you suggest: copy the file, check in
the copy, and delete the old one. In the commit logs, note where the "new"
file came from and the "old" file went.
Ultimately, which approach you take depends on which you value more: the
history within each file, or the history of the module/repository as a whole.
Eric.
--
------------------------------------------------------------ -------------------
Eric Eide <eeide@cs.utah.edu> . University of Utah School of Computing
http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX
|
|
|
| Re: Reorganizing Projects while maintaining history [message #64988 is a reply to message #64976] |
Wed, 21 July 2004 15:02 |
| Eclipse User |
|
|
|
Originally posted by: bob.news.gmx.net
"Eric Eide" <eeide@cs.utah.edu> schrieb im Newsbeitrag
news:ywrischfnrf.fsf@peoa.flux.utah.edu...
> "James" == James Howe <eclipse@wingspread.imap-mail.com> writes:
>
> James> I'm using Eclipse 3.0 and I have an application which has been
> James> built up over time. Most of the code resides in a single Java
> James> project which is stored in our CVS repository. The project has
> James> reached the point where I would like to move things out into
> James> their own project. However, if I simply move the files from
> James> Project A to Project B, the files will all be 'new' in Project B
> James> and I will have lost all history associated with the files. I
> James> know there isn't a way to do this from within Eclipse, but is
> James> there a relatively easy way to accomplish this rearrangement
> James> from either the cvs command line level or through careful work
> James> within the CVS file system itself?
>
> This is a classic problem with CVS, and is addressed in the CVS FAQ:
>
> <http://www.loria.fr/~molli/cvs/cvs-FAQ/cvsfaq8.html#2C.4>
>
> and in various books about CVS, including this one (free!):
>
> <http://cvsbook.red-bean.com/>
>
> But instead of trying to be fancy --- which has its own problems ---
many
> people just do the "obvious" thing that you suggest: copy the file,
check in
> the copy, and delete the old one. In the commit logs, note where the
"new"
> file came from and the "old" file went.
>
> Ultimately, which approach you take depends on which you value more: the
> history within each file, or the history of the module/repository as a
whole.
While I totally agree with what you wrote I'd like to point out that
usually keeping the history of the repository consistent (i.e. moving
files on the client side thus creating new cvs resources and deleting old
cvs resources) is the better choice. That way you can always resurrect
old versions of the software easily, while that is considerably more
difficult with the other approach (moving on the cvs server side).
AFAIK subversion takes care of this, so maybe it's an option to import the
whole repository into subversion (if that's possible, never used it
myself) and then use subversion subsequently (including the file move).
Kind regards
robert
|
|
|
| Re: Reorganizing Projects while maintaining history [message #65059 is a reply to message #64988] |
Sat, 07 August 2004 15:43 |
| Eclipse User |
|
|
|
Originally posted by: krayspam.arcor.de
Try migrating your repositories to subversion: http://subversion.tigris.org/
It will solve your moving and renamign problems and many more.
-- Robert
"Robert Klemme" <bob.news@gmx.net> wrote in message
news:cdm0fj$r9m$1@eclipse.org...
>
> "Eric Eide" <eeide@cs.utah.edu> schrieb im Newsbeitrag
> news:ywrischfnrf.fsf@peoa.flux.utah.edu...
> > "James" == James Howe <eclipse@wingspread.imap-mail.com> writes:
> >
> > James> I'm using Eclipse 3.0 and I have an application which has been
> > James> built up over time. Most of the code resides in a single Java
> > James> project which is stored in our CVS repository. The project has
> > James> reached the point where I would like to move things out into
> > James> their own project. However, if I simply move the files from
> > James> Project A to Project B, the files will all be 'new' in Project B
> > James> and I will have lost all history associated with the files. I
> > James> know there isn't a way to do this from within Eclipse, but is
> > James> there a relatively easy way to accomplish this rearrangement
> > James> from either the cvs command line level or through careful work
> > James> within the CVS file system itself?
> >
> > This is a classic problem with CVS, and is addressed in the CVS FAQ:
> >
> > <http://www.loria.fr/~molli/cvs/cvs-FAQ/cvsfaq8.html#2C.4>
> >
> > and in various books about CVS, including this one (free!):
> >
> > <http://cvsbook.red-bean.com/>
> >
> > But instead of trying to be fancy --- which has its own problems ---
> many
> > people just do the "obvious" thing that you suggest: copy the file,
> check in
> > the copy, and delete the old one. In the commit logs, note where the
> "new"
> > file came from and the "old" file went.
> >
> > Ultimately, which approach you take depends on which you value more: the
> > history within each file, or the history of the module/repository as a
> whole.
>
> While I totally agree with what you wrote I'd like to point out that
> usually keeping the history of the repository consistent (i.e. moving
> files on the client side thus creating new cvs resources and deleting old
> cvs resources) is the better choice. That way you can always resurrect
> old versions of the software easily, while that is considerably more
> difficult with the other approach (moving on the cvs server side).
>
> AFAIK subversion takes care of this, so maybe it's an option to import the
> whole repository into subversion (if that's possible, never used it
> myself) and then use subversion subsequently (including the file move).
>
> Kind regards
>
> robert
>
|
|
|
| Re: Reorganizing Projects while maintaining history [message #597839 is a reply to message #64964] |
Wed, 21 July 2004 14:17 |
| Eclipse User |
|
|
|
Originally posted by: eeide.cs.utah.edu
"James" == James Howe <eclipse@wingspread.imap-mail.com> writes:
James> I'm using Eclipse 3.0 and I have an application which has been
James> built up over time. Most of the code resides in a single Java
James> project which is stored in our CVS repository. The project has
James> reached the point where I would like to move things out into
James> their own project. However, if I simply move the files from
James> Project A to Project B, the files will all be 'new' in Project B
James> and I will have lost all history associated with the files. I
James> know there isn't a way to do this from within Eclipse, but is
James> there a relatively easy way to accomplish this rearrangement
James> from either the cvs command line level or through careful work
James> within the CVS file system itself?
This is a classic problem with CVS, and is addressed in the CVS FAQ:
<http://www.loria.fr/~molli/cvs/cvs-FAQ/cvsfaq8.html#2C.4>
and in various books about CVS, including this one (free!):
<http://cvsbook.red-bean.com/>
But instead of trying to be fancy --- which has its own problems --- many
people just do the "obvious" thing that you suggest: copy the file, check in
the copy, and delete the old one. In the commit logs, note where the "new"
file came from and the "old" file went.
Ultimately, which approach you take depends on which you value more: the
history within each file, or the history of the module/repository as a whole.
Eric.
--
------------------------------------------------------------ -------------------
Eric Eide <eeide@cs.utah.edu> . University of Utah School of Computing
http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX
|
|
|
| Re: Reorganizing Projects while maintaining history [message #597848 is a reply to message #64976] |
Wed, 21 July 2004 15:02 |
 Robert Klemme
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
"Eric Eide" <eeide@cs.utah.edu> schrieb im Newsbeitrag
news:ywrischfnrf.fsf@peoa.flux.utah.edu...
> "James" == James Howe <eclipse@wingspread.imap-mail.com> writes:
>
> James> I'm using Eclipse 3.0 and I have an application which has been
> James> built up over time. Most of the code resides in a single Java
> James> project which is stored in our CVS repository. The project has
> James> reached the point where I would like to move things out into
> James> their own project. However, if I simply move the files from
> James> Project A to Project B, the files will all be 'new' in Project B
> James> and I will have lost all history associated with the files. I
> James> know there isn't a way to do this from within Eclipse, but is
> James> there a relatively easy way to accomplish this rearrangement
> James> from either the cvs command line level or through careful work
> James> within the CVS file system itself?
>
> This is a classic problem with CVS, and is addressed in the CVS FAQ:
>
> <http://www.loria.fr/~molli/cvs/cvs-FAQ/cvsfaq8.html#2C.4>
>
> and in various books about CVS, including this one (free!):
>
> <http://cvsbook.red-bean.com/>
>
> But instead of trying to be fancy --- which has its own problems ---
many
> people just do the "obvious" thing that you suggest: copy the file,
check in
> the copy, and delete the old one. In the commit logs, note where the
"new"
> file came from and the "old" file went.
>
> Ultimately, which approach you take depends on which you value more: the
> history within each file, or the history of the module/repository as a
whole.
While I totally agree with what you wrote I'd like to point out that
usually keeping the history of the repository consistent (i.e. moving
files on the client side thus creating new cvs resources and deleting old
cvs resources) is the better choice. That way you can always resurrect
old versions of the software easily, while that is considerably more
difficult with the other approach (moving on the cvs server side).
AFAIK subversion takes care of this, so maybe it's an option to import the
whole repository into subversion (if that's possible, never used it
myself) and then use subversion subsequently (including the file move).
Kind regards
robert
|
|
|
| Re: Reorganizing Projects while maintaining history [message #597868 is a reply to message #64988] |
Sat, 07 August 2004 15:43 |
| Eclipse User |
|
|
|
Originally posted by: krayspam.arcor.de
Try migrating your repositories to subversion: http://subversion.tigris.org/
It will solve your moving and renamign problems and many more.
-- Robert
"Robert Klemme" <bob.news@gmx.net> wrote in message
news:cdm0fj$r9m$1@eclipse.org...
>
> "Eric Eide" <eeide@cs.utah.edu> schrieb im Newsbeitrag
> news:ywrischfnrf.fsf@peoa.flux.utah.edu...
> > "James" == James Howe <eclipse@wingspread.imap-mail.com> writes:
> >
> > James> I'm using Eclipse 3.0 and I have an application which has been
> > James> built up over time. Most of the code resides in a single Java
> > James> project which is stored in our CVS repository. The project has
> > James> reached the point where I would like to move things out into
> > James> their own project. However, if I simply move the files from
> > James> Project A to Project B, the files will all be 'new' in Project B
> > James> and I will have lost all history associated with the files. I
> > James> know there isn't a way to do this from within Eclipse, but is
> > James> there a relatively easy way to accomplish this rearrangement
> > James> from either the cvs command line level or through careful work
> > James> within the CVS file system itself?
> >
> > This is a classic problem with CVS, and is addressed in the CVS FAQ:
> >
> > <http://www.loria.fr/~molli/cvs/cvs-FAQ/cvsfaq8.html#2C.4>
> >
> > and in various books about CVS, including this one (free!):
> >
> > <http://cvsbook.red-bean.com/>
> >
> > But instead of trying to be fancy --- which has its own problems ---
> many
> > people just do the "obvious" thing that you suggest: copy the file,
> check in
> > the copy, and delete the old one. In the commit logs, note where the
> "new"
> > file came from and the "old" file went.
> >
> > Ultimately, which approach you take depends on which you value more: the
> > history within each file, or the history of the module/repository as a
> whole.
>
> While I totally agree with what you wrote I'd like to point out that
> usually keeping the history of the repository consistent (i.e. moving
> files on the client side thus creating new cvs resources and deleting old
> cvs resources) is the better choice. That way you can always resurrect
> old versions of the software easily, while that is considerably more
> difficult with the other approach (moving on the cvs server side).
>
> AFAIK subversion takes care of this, so maybe it's an option to import the
> whole repository into subversion (if that's possible, never used it
> myself) and then use subversion subsequently (including the file move).
>
> Kind regards
>
> robert
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 05:09:00 GMT 2024
Powered by FUDForum. Page generated in 0.03126 seconds |
] 
Search
Help
Register
Login
Home
