SVN Repository Merge Issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

SVN Repository Merge Issues

Robert Bray-2
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: SVN Repository Merge Issues

Robert Bray-2
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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: SVN Repository Merge Issues

Mateusz Loskot
Robert Bray wrote:
> 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.

I don't see any better solution for this problem, so I give

+1

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Greg Boone
In reply to this post by Robert Bray-2
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: [hidden email]
[mailto:[hidden email]] 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals


Hi,

 

I will be checking in some modifications to the svn trunk that will change the binary compatibility for fdo.dll. Once this is done, if you update from the svn trunk and build the FDO project, you will also need to build your providers. The changes will likely go in on Monday, Dec 18.

 

The above does not affect the 3.2.x branch. The FDO binary compatibility will not change for this branch.

 

Brent.

 


Hi,

 

Some significant changes were made today, in the open-source trunk repository, for the MySQL provider. The main change was to set the connection character set to UTF8. Previously, the character set was Latin1 (the default), but the MySQL provider was passing UTF8-encoded strings to MySQL. This caused a few problems when names and strings contained non-ASCII7 characters:

 

            - After creating a datastore with non-ASCII7 name, it was not possible to open it.

            - String data inserted into tables, with double byte character sets, could not be read properly

            - Any string data inserted by FDO, into MySQL tables, was double UTF8 encoded, making it difficult for 3rd party applications to read it.

 

The changes have the following impacts on the MySQL Provider:

 

    - minimum MySQL version now 5.0.22

- when you create a new datastore, through FDO, the character set and collation are the MySQL server defaults. Previously, these were set to

  "latin1" and "latin1_bin" respectively.

    - the current open-source MySQL Provider and previous versions are no longer compatible for non-ASCII7 users.

 

MySQL Version:

 

The changes rely on some collation fixes made to MySQL somewhere between 5.0.15 and 5.0.22. Therefore, it is recommend that you upgrade to MySQL 5.0.22 before using the latest open-source MySQL Provider.

 

Datastore character set:

 

    Previously, all datastores created by FDO had default character set Latin1 and default collation Latin1_bin. With this change, the character set and collation default to that of the MySQL server. To find out what these settings currently are, connect directly to MySQL and execute the following:

 

        show variables like 'character_set_server';

        show variables like 'collation_server';

 

    You are now responsible for using a server character set and collation that matches your data. For English and Western European customers, the Latin1 character set is fine. Other customers will need to use the UTF8 character set, or a language specific one such as CP932 (Japanese). When in doubt, UTF8 is the best one to use since it is a Unicode format.

 

    The server collation determines whether your data is treated as case-sensitive or case-insensitive. This includes column contents, not just table and column names. Note that the default is usually a case-insensitive one.

   

  Server character set and collation can be set by stopping the MySQL service, modifying my.ini, and restarting the service. In my.ini, look for any:

 

       default-character-set=

 

  settings, and change these to the desired character set. The collation can be set by adding a default-collation setting to the [mysqld] section, e.g:

 

        default-collation=utf8_bin

 

    to use case-insensitive UTF8 collation.

 

    Please refer to the MySQL documentation at www.mysql.com for more information on character sets and collations.

 

Provider and Datastore Compatibility:

 

Previous versions of the MySQL provider inserted strings, via Feature Commands, that were UTF8-encoded once too many. This change fixes this problem. However, this means that pre-existing MySQL datastores can be properly accessed by both current and previous MySQL providers only if all of the following is true:

 

        - none of the character data in the datastore contains any non-ASCII7 characters

        - the default character set for the datastore is latin1

        - the default collation for the datastore is latin1_bin

        - the server character set is latin1

        - the server collation is latin1_bin.

 

    For all other cases, pre-existing datastores must be upgraded before they are accessed by the current MySQL Provider. This can be done by doing the following:

 

        - copy the datastore to SDF, using previous MySQL Provider.

        - create a new MySQL datastore, using current MySQL Provider

        - copy the above SDF data to the new datastore, using current MySQL Provider.

 

Note that the above is not an in-place conversion. You must create a new datastore for use by the current MySQL Provider.

 

Note also that datastores created by the current MySQL Provider must not be accessed by previous provider versions.

 

Just a bit more background on the above info. ASCII7 characters ( 0x00-0x7f) have the same values for their representations in various character sets. Therefore the extra UTF8 encoding, done by previous MySQL Providers, on strings to insert, had no effect. For this reason, there are no compatibility problems for datastores with only latin1_bin tables, storing only ASCII7 characters. However, for other characters, their values are different for different character sets so the extra UTF8 encoding does change their values, thus leading to the above compatibility problems.

 

 

Brent Robinson

 

 

 


_______________________________________________
fdo-announce mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-announce

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Robert Fortin
Bob,

If I understand well, it is statu quo for 3.2.x branch with no tracking
system.  For trunk and future development, it will be done in a new
repository structure.  Is that right?

RF

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Friday, January 26, 2007 10:16 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: [hidden email]
[mailto:[hidden email]] 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: SVN Repository Merge Issues

Robert Bray-2
Robert,

Yes that is the line of thinking. 3.2.x stays with the split repository structure without a defect tracking system. Trunk is merged into a new repository. My biggest concern is one of confusion and the fact that Mateusz will need a repository for PostGIS because it will be a 3.2.x provider.

Would it be practical to roll all of the changes out of trunk effectively returning it to the state of 3.2.x. Import that into the new SVN repository, then immediately branch 3.2.x, and finally re-commit the post 3.2.x changes. Am I just making work for no reason?

Bob

Robert Fortin wrote:
Bob,

If I understand well, it is statu quo for 3.2.x branch with no tracking
system.  For trunk and future development, it will be done in a new
repository structure.  Is that right?

RF

-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Greg Boone
Sent: Friday, January 26, 2007 10:16 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: [hidden email]
[[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

    

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

  


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: SVN Repository Merge Issues

Frank Warmerdam
In reply to this post by Mateusz Loskot
Mateusz Łoskot wrote:
> Robert Bray wrote:
>> 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.
>
> I don't see any better solution for this problem, so I give
>
> +1

+1

I can live with this too.  The trunk history is the key thing, and getting
things organized for the future.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Greg Boone
In reply to this post by Robert Bray-2

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: [hidden email]
[mailto:[hidden email]] 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: SVN Repository Merge Issues

Robert Bray-2
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: [hidden email]
[[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

    

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

  


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Greg Boone
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:[hidden email]]
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: [hidden email]
[[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

    
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

  


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: SVN Repository Merge Issues

Robert Bray-2
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 [[hidden email]]
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: [hidden email]
[[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

    
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

  



_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Gavin Cramer
I first read this to be in agreement with what Greg asked, and was only stopped from merging my 3.2.x changes to the trunk on Sunday by a machine failure.  Re-reading, it looks ambiguous -- Bob, do I port my outstanding 3.2.x changes to the trunk ASAP, or wait until Shawn is done?
 
Thanx
Gavin


From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Bray
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 [[hidden email]]
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: [hidden email]
[[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

    
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

  



_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Greg Boone
In reply to this post by Robert Bray-2

I will let everyone know when the merge is complete.

 


From: Robert Bray [mailto:[hidden email]]
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 [[hidden email]]
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: [hidden email]
[[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
    
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
  

 

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Greg Boone
In reply to this post by Robert Bray-2

The Merges from 3.2.x -> Trunk should now be complete in all FDO SVN repositories.

 

Greg

 


From: Robert Bray [mailto:[hidden email]]
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 [[hidden email]]
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: [hidden email]
[[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
    
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
  

 

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: SVN Repository Merge Issues

Robert Bray-2
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 [[hidden email]]
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 [[hidden email]]
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: [hidden email]
[[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
    
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
  

 

 



_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Greg Boone
In reply to this post by Robert Bray-2

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:[hidden email]]
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 [[hidden email]]
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 [[hidden email]]
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: [hidden email]
[[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
    
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
  

 

 

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Traian Stanev
If the makefiles are set up right, one should be able to change directory to where the provider is and run make from in there. This would make it so that only that provider builds. That's how Mapguide currently works -- if I change directory to /Server and run make, only the server components will build.
 
Traian


From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Monday, January 29, 2007 6:36 PM
To: Robert Bray
Cc: FDO Internals Mail List; Shawn Barnes
Subject: RE: [fdo-internals] SVN Repository Merge Issues

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:[hidden email]]
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 [[hidden email]]
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 [[hidden email]]
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: [hidden email]
[[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
    
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
  

 

 

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Greg Boone
In reply to this post by Robert Bray-2

Your example is valid but does not answer the question I asked.

 

1)       If a user runs the following from the top directory, should this action build FDO and all providers?

 

        automake

        autoconf

        ./configure

        make

 

2)       Another question, should I be able to run ./configure from a Provider subdirectory or will we only be able to run ./configure from the root directory?

 

Greg

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Traian Stanev
Sent: Tuesday, January 30, 2007 10:29 AM
To: FDO Internals Mail List; Robert Bray
Cc: Shawn Barnes
Subject: RE: [fdo-internals] SVN Repository Merge Issues

 

If the makefiles are set up right, one should be able to change directory to where the provider is and run make from in there. This would make it so that only that provider builds. That's how Mapguide currently works -- if I change directory to /Server and run make, only the server components will build.

 

Traian

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Monday, January 29, 2007 6:36 PM
To: Robert Bray
Cc: FDO Internals Mail List; Shawn Barnes
Subject: RE: [fdo-internals] SVN Repository Merge Issues

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

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: SVN Repository Merge Issues

Greg Boone
In reply to this post by Robert Bray-2
Are the 3.2.x branches still open for submissions?

-----Original Message-----
From: shawn barnes [mailto:[hidden email]]
Sent: Tuesday, January 30, 2007 8:59 AM
To: Robert Bray
Cc: Greg Boone; FDO Internals Mail List
Subject: Re: [fdo-internals] SVN Repository Merge Issues

Bob,

I'm starting the merge now.

I'm pulling a complete backup of the repositories now (9am EST) and then
take the repositories down.

Merge everything and then put everything backup including the new merged
repository.

Question on naming.  What is the name of the new merged repository?
(repository names can be easily changed)

shawn

Robert Bray wrote:
> 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:[hidden email]]
>> *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:[hidden email]]
>>     *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: [hidden email]
<mailto:[hidden email]>
>>
>>     [mailto:[hidden email]] 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
>>>     [hidden email]
<mailto:[hidden email]>
>>>     http://lists.osgeo.org/mailman/listinfo/fdo-internals
>>>      
>>>        
>>     _______________________________________________
>>
>>     fdo-internals mailing list
>>
>>     [hidden email]
<mailto:[hidden email]>

>>
>>     http://lists.osgeo.org/mailman/listinfo/fdo-internals
>>
>>      
>>
>>     _______________________________________________
>>
>>     fdo-internals mailing list
>>
>>     [hidden email]
<mailto:[hidden email]>

>>
>>     http://lists.osgeo.org/mailman/listinfo/fdo-internals
>>
>>      
>>
>>      
>>
>>      
>>
>>  
>>
>


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: SVN Repository Merge Issues

Robert Bray-2
In reply to this post by Greg Boone
Greg,

I would take a two step approach to this.

Step #1 - Keep the build process as is for now and just fix it up.
Step #2 - Update to a single automake/autoconf script. All providers should be the default, but the user should be able to build a subset by setting one or more ./configure option(s).

Let's get Step #1 done right away. Then we can schedule Step #2 to be done sometime later as part of the FDO 3.3 release.

Bob

Greg Boone wrote:

Your example is valid but does not answer the question I asked.

 

1)       If a user runs the following from the top directory, should this action build FDO and all providers?

 

        automake

        autoconf

        ./configure

        make

 

2)       Another question, should I be able to run ./configure from a Provider subdirectory or will we only be able to run ./configure from the root directory?

 

Greg

 


From: [hidden email] [[hidden email]] On Behalf Of Traian Stanev
Sent: Tuesday, January 30, 2007 10:29 AM
To: FDO Internals Mail List; Robert Bray
Cc: Shawn Barnes
Subject: RE: [fdo-internals] SVN Repository Merge Issues

 

If the makefiles are set up right, one should be able to change directory to where the provider is and run make from in there. This would make it so that only that provider builds. That's how Mapguide currently works -- if I change directory to /Server and run make, only the server components will build.

 

Traian

 


From: [hidden email] [[hidden email]] On Behalf Of Greg Boone
Sent: Monday, January 29, 2007 6:36 PM
To: Robert Bray
Cc: FDO Internals Mail List; Shawn Barnes
Subject: RE: [fdo-internals] SVN Repository Merge Issues

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

 



_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
12