Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Technology Project and PMC » Reorganizing Projects while maintaining history
Reorganizing Projects while maintaining history [message #64964] Tue, 20 July 2004 17:30 Go to next message
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 10:17 Go to previous messageGo to next message
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 11:02 Go to previous messageGo to next message
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 11:43 Go to previous message
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 10:17 Go to previous message
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 11:02 Go to previous message
Robert Klemme is currently offline 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 11:43 Go to previous message
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
>
Previous Topic:Convert CVS to Subversion?
Next Topic:Preference scopes and FieldEditorPreferencePage
Goto Forum:
  


Current Time: Wed Aug 20 08:55:00 EDT 2014

Powered by FUDForum. Page generated in 0.13138 seconds