RE: [wtp-dev] Need to restructure our CVS Directories

[David M Williams <david_williams@xxxxxxxxxx>]

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