Changing the arrangement of files within our SCM
Maybe this could be done when/if we move to Subversion, because of SVN's superior directory management. A lot of our testing and other management of Boost code is done on a per library basis. However, the product delivered to users is in a consolidated file hierarchy. The current CVS archive of the code is kept in that same hierarchy. I propose changing the version of Boost kept in our SCM system to be library based. The hierarchy could be like: General any array ... config conversion crc date_time ... variant wave Where each directory would have its own "boost" and "libs" subdirectories. (And maybe a "src" directory if we use this opportunity to move mandatory source code to a higher level.) The "General" directory is for all the administration and other files that are not part of any library. We could move each tool (e.g. BCP, Quickbook, inspect, build, etc.) to this level too. We would have to rename the directory for the Wave tool to "wave-tool" to minimize confusion. For users, we create a final archive by copying the _contents_ of each top-level directory, recursively merging the contents of repeated child directories. From their perspective, nothing has changed. Building changes radically for developers _of_ Boost code, though. They have to add the include directories for each library separately into their compiler/IDE search list. It sounds like harder work, but it's actually a good thing because it forces us to consider dependencies between libraries. It allows us to analyze each library separately. Each library can also be downloaded separately (with CVS/SVN), like we used to do a long time ago with ZIP files. I think this arrangement would synergize with the Release Overview proposal at <http://mysite.verizon.net/beman/release_overview.html>. Both proposals are supposed to help with the scaling-up of Boost. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
I propose changing the version of Boost kept in our SCM system to be library based. The hierarchy could be like:
General any array ... config conversion crc date_time ... variant wave
Where each directory would have its own "boost" and "libs" subdirectories.
FYI... A previous discussion with similar vein I brought up long ago: http://thread.gmane.org/gmane.comp.lib.boost.devel/113512/focus=113512 -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Daryle Walker <darylew@hotmail.com> writes:
For users, we create a final archive by copying the _contents_ of each top-level directory, recursively merging the contents of repeated child directories. From their perspective, nothing has changed.
Building changes radically for developers _of_ Boost code, though.
Wouldn't that mean developers _of_ Boost code would be working with a different system of include paths than users? Seems like it coudl lead to hard-to-find bugs?
I think this arrangement would synergize with the Release Overview proposal at <http://mysite.verizon.net/beman/release_overview.html>. Both proposals are supposed to help with the scaling-up of Boost.
How? Any proposal to radically alter the way we do things ought to actually explain its benefits and how they will be achieved, and also what problem the proposal is solving. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 7/22/06 8:01 PM, "David Abrahams" <dave@boost-consulting.com> wrote:
Daryle Walker <darylew@hotmail.com> writes:
For users, we create a final archive by copying the _contents_ of each top-level directory, recursively merging the contents of repeated child directories. From their perspective, nothing has changed.
Building changes radically for developers _of_ Boost code, though.
Wouldn't that mean developers _of_ Boost code would be working with a different system of include paths than users? Seems like it coudl lead to hard-to-find bugs?
The compiler/IDE searches for file paths among the union of its list of directories. The partitioning of the files among the search directories shouldn't matter as long as each file's relative path is distinct. Each file in the current archive will move to exactly one of the new library directories. There shouldn't be any duplication. This plan will work better with Subversion, since that SCM system records file _and_ directory moves. This allows us to move one library/tool at a time, leaving the rest in the "General" directory.
I think this arrangement would synergize with the Release Overview proposal at <http://mysite.verizon.net/beman/release_overview.html>. Both proposals are supposed to help with the scaling-up of Boost.
How?
Beman wants us to move from monolithic releases to releasing whenever a library gets a finalized update (or a few updates are built up). He also wants to allow libraries to be updated asynchronously. Separating eases counting, or otherwise iterating, over each library (like regressions, other testing, making an automatic "libraries.html"). It's also easier to add a new library, if the author makes his/her archive mirror the final (user-level) directories, because our scripts will handle the merges. You could easily remove a retired library. It will be easier for an author to get the minimum number of files needed to change a library. You would do it by just checking out the specific library directory. Any missing dependencies will become obvious in compiling; you can similarly checkout other library directories to get an exact list of dependencies.
Any proposal to radically alter the way we do things ought to actually explain its benefits and how they will be achieved, and also what problem the proposal is solving.
We already treat each library separately in most of the things we discuss on this list. Keeping each library separate until release time helps because authors can manipulate his/her library wholesale without interfering with files from other libraries (or forgetting a file to mess with). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
This plan will work better with Subversion, since that SCM system records file _and_ directory moves.
Not strictly true. It keeps track of deletes and adds. The moves/renames are implemented in terms of those which means that getting the history of files in place is not possible. (Last I checked) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
This plan will work better with Subversion, since that SCM system records file _and_ directory moves.
Not strictly true. It keeps track of deletes and adds. The moves/renames are implemented in terms of those which means that getting the history of files in place is not possible. (Last I checked)
In subversion, moves are a copy, followed by the deletion of the original; the copy is history-preserving.
me22 wrote:
This plan will work better with Subversion, since that SCM system records file _and_ directory moves. Not strictly true. It keeps track of deletes and adds. The moves/renames are implemented in terms of those which means that getting the history of files in place is not possible. (Last I checked)
In subversion, moves are a copy, followed by the deletion of the original; the copy is history-preserving.
Somewhat, just tried the basic experiment again... The history that the file was copied from another version is kept. But viewing the history before the move is not possible without looking up the previous files history which is really hard as the file is now deleted. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On 7/24/06 12:30 AM, "Rene Rivera" <grafikrobot@gmail.com> wrote:
me22 wrote: [Rene wrote:] [I wrote:]
This plan will work better with Subversion, since that SCM system records file _and_ directory moves. Not strictly true. It keeps track of deletes and adds. The moves/renames are implemented in terms of those which means that getting the history of files in place is not possible. (Last I checked)
In subversion, moves are a copy, followed by the deletion of the original; the copy is history-preserving.
Somewhat, just tried the basic experiment again...
The history that the file was copied from another version is kept. But viewing the history before the move is not possible without looking up the previous files history which is really hard as the file is now deleted.
My language was ambiguous there, but my point wasn't that the accuracy of move wasn't perfect, it was that Subversion can handle them better than CVS. CVS can't handle file moves at all. CVS can't handle any type of directory versioning; directories are treated as eternal containers. Messing around with file moves or directory anything in CVS involves ignorant moving of the administration directories/files, leaving CVS to not acknowledge the move and think the new location was always the location. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Hi Rene ! An'n Maandag 24 Juli 2006, 06:30 hett Rene Rivera schreven:
me22 wrote:
In subversion, moves are a copy, followed by the deletion of the original; the copy is history-preserving.
Somewhat, just tried the basic experiment again...
Which client ?
The history that the file was copied from another version is kept. But viewing the history before the move is not possible without looking up the previous files history which is really hard as the file is now deleted.
Well, we've done massive code-reordering recently and I can "svn log" all the way back to revision 2 of 38000+ from my working copy. svn does all lookups behind the scene. It's most likely a client problem... When using TortoiseSVN you have to manually disable the "stop on copy/rename" button on the log page. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de
Jürgen Hunold wrote:
Hi Rene !
An'n Maandag 24 Juli 2006, 06:30 hett Rene Rivera schreven:
me22 wrote:
In subversion, moves are a copy, followed by the deletion of the original; the copy is history-preserving. Somewhat, just tried the basic experiment again...
Which client ?
That would be TortoiseSVN as you mention below :-)
The history that the file was copied from another version is kept. But viewing the history before the move is not possible without looking up the previous files history which is really hard as the file is now deleted.
Well, we've done massive code-reordering recently and I can "svn log" all the way back to revision 2 of 38000+ from my working copy. svn does all lookups behind the scene. It's most likely a client problem...
When using TortoiseSVN you have to manually disable the "stop on copy/rename" button on the log page.
Gota love, not, the terrible interface choices people make. I was using the revision graph tool which has no such option even though it's the same procedure than the log tool. I use the rev graph a lot as it's the clearest UI representation of version control systems. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
participants (5)
-
Daryle Walker -
David Abrahams -
Jürgen Hunold -
me22 -
Rene Rivera