[fdo-internals] SVN Repository Merge Issues
Greg Boone
greg.boone at autodesk.com
Mon Jan 29 18:35:41 EST 2007
Hi Bob,
When I merge the Linux build process, do you wish to have a single
'make' request initiated at the top level build FDO and all the
providers under the Providers directory? This may be overhead that is
not required for users who wish to build only a single provider.
Greg
_____
From: Robert Bray [mailto:rbray at robertbray.net]
Sent: Monday, January 29, 2007 6:24 PM
To: Greg Boone
Cc: FDO Internals Mail List; Shawn Barnes
Subject: Re: [fdo-internals] SVN Repository Merge Issues
Great, thanks Greg! Shawn can you proceed with the merge tomorrow?
Thanks,
Bob
Greg Boone wrote:
The Merges from 3.2.x -> Trunk should now be complete in all FDO SVN
repositories.
Greg
_____
From: Robert Bray [mailto:rbray at robertbray.net]
Sent: Sunday, January 28, 2007 2:41 AM
To: Greg Boone
Cc: FDO Internals Mail List; Shawn Barnes
Subject: Re: [fdo-internals] SVN Repository Merge Issues
We only have three more days of Shawn full time, so I would like to get
this done before he moves on to other things.
Bob
Greg Boone wrote:
Hi Bob,
We are still porting a few defects from 3.2.x -> trunk. I would like to
complete this process before we perform the merge.
Greg.
-----Original Message-----
From: Robert Bray [mailto:rbray at robertbray.net]
Sent: Sat 1/27/2007 3:01 AM
To: FDO Internals Mail List
Cc: Greg Boone; Shawn Barnes
Subject: Re: [fdo-internals] SVN Repository Merge Issues
This does not look too bad, but to save ourselves the hassle
let's just stick with plan A. Until further notice please avoid
submitting anything to trunk.
Shawn, can you plan to create the new FDO SVN repository on
Monday by merging all of the fdoXXX trunks?
Thanks,
Bob
Greg Boone wrote:
Hi all,
At this point, we have identified the following code submissions
that
were made in the trunk and not in 3.2.x
603
628
652
Details...
------------------------------------------------------------------------
r603 | brentrobinson | 2006-12-18 10:09:39 -0500 (Mon, 18 Dec
2006) | 1
line
Changed paths:
M /trunk/Fdo/Unmanaged/Common.vcproj
M /trunk/Fdo/Unmanaged/Fdo.vcproj
A /trunk/Fdo/Unmanaged/Inc/Common/Compare.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/ByteValue.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/DataValue.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/DateTimeValue.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/DecimalValue.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/DoubleValue.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/Int16Value.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/Int32Value.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/Int64Value.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/SingleValue.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/StringValue.h
M /trunk/Fdo/Unmanaged/Inc/Fdo/Schema/MergeContext.h
M
/trunk/Fdo/Unmanaged/Inc/Fdo/Schema/PropertyValueConstraint.h
M
/trunk/Fdo/Unmanaged/Inc/Fdo/Schema/PropertyValueConstraintList.h
M
/trunk/Fdo/Unmanaged/Inc/Fdo/Schema/PropertyValueConstraintRange.h
M /trunk/Fdo/Unmanaged/Inc/FdoCommon.h
M /trunk/Fdo/Unmanaged/Inc/Makefile.am
M /trunk/Fdo/Unmanaged/Src/Fdo/Expression/ByteValue.cpp
M /trunk/Fdo/Unmanaged/Src/Fdo/Expression/DataValue.cpp
M /trunk/Fdo/Unmanaged/Src/Fdo/Expression/DateTimeValue.cpp
M /trunk/Fdo/Unmanaged/Src/Fdo/Expression/DecimalValue.cpp
M /trunk/Fdo/Unmanaged/Src/Fdo/Expression/DoubleValue.cpp
A
/trunk/Fdo/Unmanaged/Src/Fdo/Expression/ExpressionInternal.cpp
A
/trunk/Fdo/Unmanaged/Src/Fdo/Expression/ExpressionInternal.h
M /trunk/Fdo/Unmanaged/Src/Fdo/Expression/Int16Value.cpp
M /trunk/Fdo/Unmanaged/Src/Fdo/Expression/Int32Value.cpp
M /trunk/Fdo/Unmanaged/Src/Fdo/Expression/Int64Value.cpp
M /trunk/Fdo/Unmanaged/Src/Fdo/Expression/SingleValue.cpp
M /trunk/Fdo/Unmanaged/Src/Fdo/Expression/StringValue.cpp
M /trunk/Fdo/Unmanaged/Src/Fdo/Makefile.am
M
/trunk/Fdo/Unmanaged/Src/Fdo/Schema/DataPropertyDefinition.cpp
M /trunk/Fdo/Unmanaged/Src/Fdo/Schema/MergeContext.cpp
M
/trunk/Fdo/Unmanaged/Src/Fdo/Schema/PropertyValueConstraintList.cpp
M
/trunk/Fdo/Unmanaged/Src/Fdo/Schema/PropertyValueConstraintRange.cpp
M /trunk/Fdo/Unmanaged/Src/Message/FDOMessage.mc
FDO342: Support SDF constraint update.
------------------------------------------------------------------------
r628 | brentrobinson | 2007-01-12 17:38:53 -0500 (Fri, 12 Jan
2007) | 1
line
Changed paths:
M /trunk/Fdo/Unmanaged/Inc/Fdo/Expression/DoubleValue.h
Removed circular friend reference
------------------------------------------------------------------------
r652 | brentrobinson | 2007-01-23 16:21:24 -0500 (Tue, 23 Jan
2007) | 1
line
Changed paths:
M /trunk/Fdo/Unmanaged/Fdo.vcproj
M /trunk/Fdo/Unmanaged/Inc/Fdo/Raster/DataValueCollection.h
M
/trunk/Fdo/Unmanaged/Inc/Fdo/Raster/IRasterPropertyDictionary.h
M /trunk/Fdo/Unmanaged/Inc/Fdo.h
Deprecated redundant Inc/Fdo/Raster/DataValueCollection.h.
------------------------------------------------------------------------
-----Original Message-----
From: Greg Boone
Sent: Friday, January 26, 2007 10:15 AM
To: 'FDO Internals Mail List'
Cc: Shawn Barnes
Subject: RE: [fdo-internals] SVN Repository Merge Issues
In response to your question, "At this point in time, how
different is
trunk and 3.2.x", the branch and trunk are mostly identical but
not
totally identical. Our decision with branching 3.2.x was that
all
changes submitted into the 3.2.x branch should also be submitted
into
the trunk. I will have to verify that this is the case. I will
look into
this and get back to you.
I know of a couple of submissions that went into the trunk that
did not
go into the 3.2.x branch. There were several by Brent R. that
come
immediately to mind (See attached) One significant difference is
that
Brent dropped a change in the trunk of FDO that changed binary
compatibility between the branch and trunk.
Greg
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of
Robert Bray
Sent: Friday, January 26, 2007 1:06 AM
To: FDO Internals Mail List
Cc: Shawn Barnes
Subject: Re: [fdo-internals] SVN Repository Merge Issues
Hmm,
No responses. So everyone is ok with this, everyone is
dumbfounded and
shocked into silence, or?
Any better ideas for how to deal with this merge? We need to
make a
decision and move forward.
At this point in time, how different is trunk and 3.2.x?
Bob
Robert Bray wrote:
All,
Shawn has been tinkering with this and has been able to
successfully
merge trunk. However it looks like we will not be able
to merge the
branches. You can see a preview of the merged repository
here:
http://test.osgeo.net/trac/fdo-merged/browser/.
Merging in SVN alters the revision numbers, which is why
the branch
merges do not work. Here is the summary from Shawn:
"I've searched and
spoken with a few people on subversion merges and
consensus is,
branches and tags are broken on projects that are being
merged into
another project, due to the fact that the tag/branch
repository
specific and don't translate to a new repository
structure."
So it looks like we may need to have an OLD COLLECTION
OF REPOSITORIES
(3.2.x) and a NEW REPOSITORY (3.3.x and beyond). This is
not ideal but
I do not know what else to do at this point.
Thoughts and ideas welcome?
Bob
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20070129/bc348626/attachment-0001.html
More information about the fdo-internals
mailing list