[fdo-internals] RE: Random question
Greg Boone
greg.boone at autodesk.com
Fri Mar 6 14:08:50 EST 2009
Please submit all your existing sandbox code submitted by Monday. At that point I will move the existing sandbox code into sandbox/3.4.0.
Greg
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 1:37 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
I also like the idea of have per-feature or per-release sandboxes rather than per-user sandboxes
ie:
sandbox/3.4.0
sandbox/3.4.0_ArcSDE93
sandbox/3.3.2_Performance
Greg
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 1:26 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
Typically in this case, the developer would sandbox the latest version (let's say 3.4) and the port the changes back to 3.3. I can say that right now because the code streams for 3.3 and 3.4 are very similar. However, I have not given much thought to the whole idea of sandboxing a previous development stream. Usually such changes as that are done in a sandbox in preparation of being submitted into the trunk. I can see how use can you describe can be useful, but don't think it will be a large part of whatever sandboxing occurs.
In any case, if developers want their own sandbox, I won't stand in the way. It would be easy to move the current sandbox into a subfolder.
Greg
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Friday, March 06, 2009 1:19 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
Right...
But what if someone wanted to make some relatively intrusive changes to
a provider against two different branches of FDO (say, 3.4 and 3.3) to
fix a particular defect or performance problem?
Jason
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: March-06-09 10:09 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
I think that the only item the current setup would not support is #2,
the issue of isolation. But since we are provider driven, is there a
chance we will have multiple people sandboxing the same provider? I like
the idea of a common sandbox as it allows you to immediately determine
if the changes others are working on will work with the changes you are
making without breaking the build in the trunk, etc. Sandbox changes to
FDO itself can immediately be seen and their worth be assessed by all
provider developers.
However, this is my philosophy. If you really need a sandbox for your
own development, we could set something up.
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
More information about the fdo-internals
mailing list