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.
- Konstantin
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David M Williams
Sent: Tuesday, October 23, 2007 8:29 PM
To: General discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] Need to restructure our CVS Directories
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" 1.1.1.4 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,
"Konstantin Komissarchik" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
10/23/2007 03:47 PM
Please respond to
"General discussion of project-wide or architectural issues."
<[email protected]>
To
"General discussion of project-wide or architectural issues."
<[email protected]>
cc
Subject
RE: [wtp-dev] Need to restructure our CVS Directories
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
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David M Williams
Sent: Tuesday, October 23, 2007 12:10 PM
To: [email protected]
Subject: [wtp-dev] Need to restructure our CVS Directories
http://wiki.eclipse.org/WTP_CVS_Restructuring
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 next I-build!
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.
Additionally, 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.
Comments welcome.
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._______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
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._______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
