You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Clark, Ken" <Ke...@pfizer.com> on 2006/04/20 20:01:23 UTC

Advice for use of Subversion

We have an existing production system that uses CVS as its CM store.  There is ongoing maintenance against a branch (the most recent major release).

We have another project which is about to come on line.  One of its major activities is to convert about 1/4 the code base to use an upgraded framework.  In order to do the upgrade, the easiest path is to break a single monolithic code tree into a number of smaller subsections.  This must at least be done at build time to comply with the new FW.  But it would be better still to alter the layout of the source code also, along the same lines as the deployment.  

In CVS, of course, this could not be done without abandoning the original repository, and along with it the ability to merge the maintenance code changes with the new development.

We are considering using Subversion instead because it appears that this should be possible.

Some questions:

1) First, will Subversion allow us to merge code changes from a branch to code changes on HEAD, even when the code is completely reorganized in HEAD
2) If so, is there anything we need to pay particular attention to when reorganizing to ensure this works?  It seems like we would not be able to simply move a file and commit -- we must need to tell Subversion that the new file used to be the old file.
3) Assuming that #2 requires careful submission of commands to Subversion while moving files -- does Eclipse/Subclipse, IntelliJ 5.x, or some other tool do a better job of managing this?
4) Is there a way to convert a CVS repository, history and all, into a Subversion repository.  Does anyone have experience in particular doing this for a SourceForge Enterprise Edition CVS/SVN installation (SFEE has some internal data to link CM commits to objects within SFEE)


Thanks,
Ken Clark
Principal Consultant,  Tourtellotte Consulting
860.732.0206

----------------------------------------------------------------------
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be privileged.  It is intended for the addressee(s) only.  Access to this E-mail by anyone else is unauthorized.  If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful.  If you are not an addressee, please inform the sender immediately.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org


Re: Subclipse move [was: Advice for use of Subversion]

Posted by Andreas Pakulat <ap...@gmx.de>.
On 20.04.06 20:41:36, Mark Phippard wrote:
> Andreas Pakulat <ap...@gmx.de> wrote on 04/20/2006 05:32:22 PM:
> 
> > On 20.04.06 16:09:41, Mark Phippard wrote:
> > > "Clark, Ken" <Ke...@pfizer.com> wrote on 04/20/2006 04:01:23 PM:
> > > > 3) Assuming that #2 requires careful submission of commands to 
> > > Subversion 
> > > > while moving files -- does Eclipse/Subclipse, IntelliJ 5.x, or some 
> > > other tool
> > > > do a better job of managing this?
> > > 
> > > I can speak for Subclipse.  It will capture a copy/move/refactoring 
> > > operation and run the command for you.
> > 
> > I'd like to jump in here and ask you: Are your absolutely sure that
> > Subclipse does a svn move when moving or renaming a file?
> 
> I am 100% sure.  I am one of the Subclipse project owners.

I suspected that :-) 

> > I'm asking
> > because one can't really tell from the list of changed files upon
> > committing, it only lists the new filename as added and the old one as
> > deleted - the same is shown when doing svn move on the command line.
> > That's why I always used svn move on the command line to rename/move
> > files around.
> 
> That is because that is the way Subversion lists a move.  The svn move 
> command is implemented as a Copy (add) followed by a Delete.  In Eclipse 
> if you show the Console view you can see all of the commands we execute 
> and their output.

I do know about the svn-console, but it seems I never looked at it after
a move. 

Thanks for the info, now I can assure my co-workers that we don't loose
history due to using subclipse :-)

Andreas

-- 
You may worry about your hair-do today, but tomorrow much peanut butter will
be sold.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subclipse move [was: Advice for use of Subversion]

Posted by Mark Phippard <ma...@softlanding.com>.
Andreas Pakulat <ap...@gmx.de> wrote on 04/20/2006 05:32:22 PM:

> On 20.04.06 16:09:41, Mark Phippard wrote:
> > "Clark, Ken" <Ke...@pfizer.com> wrote on 04/20/2006 04:01:23 PM:
> > > 3) Assuming that #2 requires careful submission of commands to 
> > Subversion 
> > > while moving files -- does Eclipse/Subclipse, IntelliJ 5.x, or some 
> > other tool
> > > do a better job of managing this?
> > 
> > I can speak for Subclipse.  It will capture a copy/move/refactoring 
> > operation and run the command for you.
> 
> I'd like to jump in here and ask you: Are your absolutely sure that
> Subclipse does a svn move when moving or renaming a file?

I am 100% sure.  I am one of the Subclipse project owners.

> I'm asking
> because one can't really tell from the list of changed files upon
> committing, it only lists the new filename as added and the old one as
> deleted - the same is shown when doing svn move on the command line.
> That's why I always used svn move on the command line to rename/move
> files around.

That is because that is the way Subversion lists a move.  The svn move 
command is implemented as a Copy (add) followed by a Delete.  In Eclipse 
if you show the Console view you can see all of the commands we execute 
and their output.

Mark


_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________

Subclipse move [was: Advice for use of Subversion]

Posted by Andreas Pakulat <ap...@gmx.de>.
On 20.04.06 16:09:41, Mark Phippard wrote:
> "Clark, Ken" <Ke...@pfizer.com> wrote on 04/20/2006 04:01:23 PM:
> > 3) Assuming that #2 requires careful submission of commands to 
> Subversion 
> > while moving files -- does Eclipse/Subclipse, IntelliJ 5.x, or some 
> other tool
> > do a better job of managing this?
> 
> I can speak for Subclipse.  It will capture a copy/move/refactoring 
> operation and run the command for you.

I'd like to jump in here and ask you: Are your absolutely sure that
Subclipse does a svn move when moving or renaming a file? I'm asking
because one can't really tell from the list of changed files upon
committing, it only lists the new filename as added and the old one as
deleted - the same is shown when doing svn move on the command line.
That's why I always used svn move on the command line to rename/move
files around.

Andreas

-- 
Chess tonight.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Advice for use of Subversion

Posted by "Mike.Brenner" <mi...@mitre.org>.
> The main benefit you get from Subversion's move support 
 > is that the history is maintained.

While that may be the "main" benefit,
other use cases emphasize
the collaboration aspect of svn,
and have much less use for the history.

Let's say "svn move" always deleted the history.
During reorganization of some projects, that
could actually provide an advantage.

Certainly we derive a large benefit
from "svn move" of large directory trees
(over cvs) regardless of whether the
history gets preserved, because cvs
required each directory to be
"cvs add"ed individually. (Assuming
you meet the requirements for an
"svn move" to work.)

When I go in to fix a broken project,
"svn copy" and "svn move" serve
very useful purposes. A "remove history"
button would also be useful at that point.
Almost all "copies" and "moves"
involve points in the development
where you would like to start a
brand new history.

Another point is licensing. At the
place where you change licensing,
say, at the point where you
transfer a portion of the technology
to Open Source, LGPL, Jakarta,
Sun Community, etc., the history
could generate future misunderstandings
that we can only avoid by deleting
that history at that point.

Mike


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Advice for use of Subversion

Posted by Mark Phippard <ma...@softlanding.com>.
"Clark, Ken" <Ke...@pfizer.com> wrote on 04/20/2006 04:01:23 PM:

> 1) First, will Subversion allow us to merge code changes from a branch 
to code
> changes on HEAD, even when the code is completely reorganized in HEAD

Not really.  If the item has been moved in trunk when you merge the 
changes from the branch it will not find the new location.  You'd have to 
use svn diff to create a patch and then apply it to the new location.  At 
least I can imagine that would work.

The main benefit you get from Subversion's move support is that the 
history is maintained.  The feature you need is on the wish-list.  Some 
preliminary work has been done but it will probably take a few more 
releases before it is completely implemented.

> 2) If so, is there anything we need to pay particular attention to when 
> reorganizing to ensure this works?  It seems like we would not be able 
to 
> simply move a file and commit -- we must need to tell Subversion that 
the new 
> file used to be the old file.

SVN provides a full complement of subcommands like copy, move, delete that 
you need to use.

> 3) Assuming that #2 requires careful submission of commands to 
Subversion 
> while moving files -- does Eclipse/Subclipse, IntelliJ 5.x, or some 
other tool
> do a better job of managing this?

I can speak for Subclipse.  It will capture a copy/move/refactoring 
operation and run the command for you.

> 4) Is there a way to convert a CVS repository, history and all, into a 
> Subversion repository.  Does anyone have experience in particular doing 
this 
> for a SourceForge Enterprise Edition CVS/SVN installation (SFEE has some 

> internal data to link CM commits to objects within SFEE)

There is the cvs2svn project which does an excellent job converting 
repositories.

http://cvs2svn.tigris.org/

Mark


_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org