info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Common code base for different projects


From: Greg A. address@hidden (Greg A. Woods)
Subject: Re: Common code base for different projects
Date: Fri, 31 Aug 2001 01:11:46 -0400 (EDT)

[ On Thursday, August 30, 2001 at 11:22:20 (-0400), Arcin Bozkurt - Archie 
wrote: ]
> Subject: Re: Common code base for different projects
>
> >>Q) Without loosing the history for those files, how do I move them out
> >>of the current module, and create a seperate module for them. Would
> >>moving the ,v files in the repository do the job?
> >>
> >
> >It all depends on the history of your repository, including how and when
> >it was created.
> >
> well, they are big... at least I don't want to loose the history of 
> those files.

You didn't say anything about the rest of your repository -- how any
tags on these files are related to other non-shared files, where these
files are located w.r.t. other modules, etc., etc., etc.

> Because they are in continuous development, and there may be things we 
> may want to refer back. There are many Tag's on those files that I want 
> to keep.

Ah, but you're going to have to change your process for dealing with
those shared files if you're going to put them into a common module and
separately release manage them.

Indeed you will probably have to change from using a "continuous"
evolutionary style of development for these files to a more controlled
and staged form where releases are defined and created for use by the
other projects.  This is a (VERY) good thing for your overall process
though!  If it's done right it'll help better define the features and
facilities provided by these common files so that every other user of
them will better know what to expect from them and so that changes in
them will be mediated in such a way as to allow each project that uses
them a chance to prepare for those changes.

> >Why not start a new project with a canonical copy of those files?
> >
> >(i.e. why not create a new module, check out an empty working directory
> >for them [cvs -f co newmodule], copy the files into the new working
> >directory and then add them all to the new repository with "cvs add"?)
> >
> Well, this way i lose the history and any tags, etc.

No, you will not.

You will not lose the revision history or the tags, or anything else.
Those files will presumably still be in your repository and you can
still refer to them under their old names in their previous locations.
Nothing will be lost.

So, I ask again, why not start with a fresh new module to contain the
shared files, starting with their present state?
 
Indeed one of the most important reasons for starting fresh with the new
module is so that you can leave the old files mostly undisturbed (you
might "cvs remove" them, but that's OK).

The worst thing you could do would be to move the files within the
repository -- that would destroy your ability to re-create previous
releases that included those files.

The second worst thing you could do would be to copy the files within
the repository.  You'd still probably have to remove the old tags on the
new copies to prevent confusion with the original files.

The best thing to do is to leave the old files alone and to simply
create a new module that starts with a "cvs add" of each file that is to
become a component in it.

If you have to "cvs rm" the files to prevent future confusion with them
in their present location then all you have to do is to tag (with an
ordinary tag, *NOT* a branch tag) the module(s) they are in now to
represent their "final" state before the cut-over to the new structure.
You can then still check out the old module(s) using that tag to see
them in their frozen final state.  From within that checked out but
frozen working directory you can also use "cvs log", "cvs diff" etc. to
examine their old history.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]