Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] Need to restructure our CVS Directories


I realized later that we actually declare our M3 on Wednesday, 11/14, so I think the afternoon of the 14th would be best.

I've outlined some more detailed schedule of "to do" items which hopefully makes it clearer that's expected of each project lead and what committers should do to prepare.

http://wiki.eclipse.org/WTP_CVS_Restructuring#To Do Items and Schedule

As always, questions and comments are welcome.

Thanks,








"Konstantin Komissarchik" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

10/24/2007 09:07 PM

Please respond to
"General discussion of project-wide or architectural issues."        <wtp-dev@xxxxxxxxxxx>

To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
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.
 
- Konstantin
 


From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] 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" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

10/23/2007 03:47 PM

Please respond to
"General discussion of project-wide or architectural issues."        <wtp-dev@xxxxxxxxxxx>


To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
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: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent:
Tuesday, October 23, 2007 12:10 PM
To:
wtp-dev@xxxxxxxxxxx
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
wtp-dev@xxxxxxxxxxx
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
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev


Back to the top