RE: [wtp-dev] Need to restructure our CVS Directories
If at all possible, let's target this to start of M4
(11/16). I imagine most people naturally divide their feature work among
milestones and doing this re-structuring at the boundary between milestones will
be least disruptive.
What is the recommended
practice ... There's a few options, and
importing/exporting might work, but probably the worst solution. There's
probably better (or, at least additional) methods to use. The best, I think, is to create a temporary branch ... with a
name such as 'tempAndYourUserID' and commit your changes to that branch.
It would get moved with anything else, and be there
ready for you to checkout and merge back with head after the restructuring.
The problem with export/import is that all
cvs info is lost, so many files will look "new" when they really are not, and
would require more "manual" inspection to see
what was different and what was not. And, when it does get checked in, I think
starts the revision numbers from a top level
... instead of maintaining the exact history -- for example, it'd be checked in
as new, and given revision 1.3, instead of "branching off" 188.8.131.52 or 1.2.1 (as
some examples). You could also create a
big patch (or a few) and keep a copy locally as another form of backup of your
work in progress. I've done some simple
tests, and seems like patches created against the old can be applied to the new
.. and that's workspace or project patches ... remarkable, but, sort of makes
sense if you look at the patch file ... the module name and module relative path
is all there in the patch file. .... should be communicated at least a few days in advance.
That's reasonable. I think the candidate dates
are on a Friday, after main builds of the week. 10/26 11/02 11/09 11/16 <-- this is
the "post M3" date. I have yet to talk to
the Eclipse webmasters about it, so they might have some insights on the methods
and timing. If anyone has any questions
please ask ... or objections, please say. Thanks,
What is the recommended practice for carrying changes over
than are not committed before this happens? Will exporting the patch from the
old locations and importing patches into new locations work or do we need to do
something else? I am in a middle of some feature work that I am not yet ready to
release and I don't like the idea of committing changes before they are ready to
be released. I have to say that this is pretty poor timing. With most of
the committers doing feature work right now (which typically involves longer
cycles before the work can be committed), I imagine there would be other people
who would find themselves in a similar situation to my own. It would be better,
in my opinion, to wait until we are in a bug fix mode (probably some time in the
Spring) when most people will not be holding on to changes for a long time and
it will be easier to agree on a date.
At the very least the exact date/time of
when this will happen should be communicated at least a few days in
advance. - Konstantin
10/23/2007 03:47 PM
"General discussion of project-wide or architectural issues."
|"General discussion of project-wide
or architectural issues." <wtp-dev@xxxxxxxxxxx>
|RE: [wtp-dev] Need to restructure
our CVS Directories|
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of David M
Sent: Tuesday, October 23, 2007 12:10 PM
Subject: [wtp-dev] Need to restructure our CVS
See the above document for the
reasons why ... or, the reasons why I think it is necessary and desirable.
Initially I was
thinking we'd do this "after the next milestone", but some I have talked to said
"the sooner the better". Which, as far as I know, might be as early as after the
So, please take a few minutes to understand the issues, and complain
if that seems too disruptive too early.
The main disruption for committers is that you will
have to create a new workspace ... and re-checkout freshly any projects you have
in your workspace!
Hence, any code that "you have almost ready to check in"
should be checked in ... even if not quite released for a build this week.
any adopters that literally build WTP will have to adjust as well.
Also, I know there are some
teams (such as VE) that have "team project sets" that will have to be updated to
pull from the new repository locations.
Not to mention, our map files and perhaps our build
will have to be modified to find the code. I would not be surprised if we don't
have good builds for a few days while issues are sorted out.
So, it's no small chore.
Notice: This email
message, together with any attachments, may contain information of BEA Systems,
Inc., its subsidiaries and affiliated entities, that may be confidential,
proprietary, copyrighted and/or legally privileged, and is intended solely for
the use of the individual or entity named in this message. If you are not the
intended recipient, and have received this message in error, please immediately
return this by email and then delete it._______________________________________________
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.