Sharing Code Between Projects

Someone at Real World asked me about maintaining shared code between projects in Real Studio. He was using external project items (in XML format) and that makes it difficult to work with source control since the XML format isn’t really designed for that. We have a lot of code that we share between projects, both code that we’ve written like ActiveRecord and open source code or libraries that we’ve purchased.

We don’t try to share the code automatically. Instead we keep shared code in a separate project (ideally with testing code, although we’re not at 100%). That code is separately versioned and we update individual projects by copying the new version into the project’s that use it.

In our experience this works much better than trying to share code automatically. We work on a lot of projects and sometimes a project won’t have changes for months or even years. If the shared code has changed in the meantime, we don’t want to go back to the project that uses it and find that it may have bugs that were introduced by changes to the shared code.

This applies to other language also by the way. I can’t see myself ever having code shared between separate projects (with the exception of header files in C or C++).

If you search for vendor branches you can find some more information that’s specific to Subversion. We don’t use the vendor branch pattern ourselves but it’s worth knowing about.

14 thoughts on “Sharing Code Between Projects

  1. And to merge these separately maintained project items, Arbed’s “Compare Projects” feature is the perfect tool for it! 🙂
    I use it all the time for that purpose.

    (http://www.tempel.org/Arbed)

  2. Agreed, I determined long ago that automatic code sharing between projects is bad practice. It’ll provide short-term convenience, but long-term headaches. The only time I’d consider it a good idea is if you have a suite of tightly bound projects, or a master/helper relationship.

  3. Completely agree, don’t have code in one project automatically updated by changes to another project.

    A good compromise is something like git submodules, they are versioned with your main project, so while you pull the directory from a common library project, it’s up to you as to when you do it, never forced by changes made elsewhere. This way the library doesn’t change unless you explicitly ask for a newer version.

  4. This is a great point. I attempted to have shared code and it created a disaster of projects that wouldn’t compile. One of my biggest regrets and biggest messes I’ve ever made of my code.

  5. @Thom,
    Good point. There’s an exception to every rule and a helper app is a case where I would consider code sharing if Real Studio had better support for it (i.e. using VCP format).

  6. While I’ve never done auto code sharing with another developer on a single project I don’t agree with you guys that it can’t be done well. I have no idea how VCP or whatever it is works but I would think if the code share/update was done correctly it should work well and benefit the project, and each coder.

    I’ll give you guys a similar real world example of why I feel this way.

    This was a long time ago so the exact details may be missing as I might have forgotten them.

    Many years ago I used to collaborate making music via internet with other musicians and we’d swap project files of our tracks adding them into our own projects building a song of collaborated music. One musician would be working on the drum tracks, while another would add his bass line, multiple guys on guitars, vocals, etc. All swapping tracks with each other while not changing the other musician’s tracks.

    Each musician could add, edit, change their own tracks as much as they wanted and it wouldn’t effect other author’s tracks. It worked great and was a lot of fun. Originally the updates were manually done having to swap project files via FTP or direct chat transfer but after some time we did it automatically just using a ‘post track’ button and a separate app to auto send the tracks to a central server where others would auto download and add the tracks to their projects. It was great.

    RB side note : I was going to make a large music collaboration project using RB but it had too many bugs and I ended up dumping the project. I had already put many months into it but after a while I got too frustrated with all the bugs and problems so I gave up.

    The reason why it worked was because only the author edited his own music and adding new updates from other authors didn’t change anything else but their own tracks.

    If RS code sharing were properly handled with each coder’s code labeled with their own ID in the XML file (perhaps comment tag lines encompassing the code) acting as a lock protecting the code disallowing edits from proxy coders I think it would work fine.

    By allowing coders only to edit their own code I don’t see why auto updating wouldn’t work well?
    The owner of the localized project could override the proxy code locally (but not by proxy) if he wanted to edit or ignore the proxy coder’s code. In turn the proxy coder receiving those new edits could approve or disapprove of them locally.

    Before the code amendments a save should be performed saving the local coder’s work before amending the new code from the proxy coder.

    Maybe I didn’t explain it well but something like that done correctly I would think would work well.

  7. @Sh3ppard
    Lot of “if it were handled properly” statements in your comment. I think that’s our point. Real Studio’s format along with subversion don’t make it easy. It’s not that it can’t be done but it’s really, really hard. Ideally you’d want something that is easy and bulletproof.

    Plus, in our case, each client project is its own island. Code sharing is verboten even if they use our standard toolkit (which is common across all projects).

  8. @Bob: I haven’t really looked at an RS XML file in detail but if the comment lines could be used as coder ID tags to bracket code (acting as a lock/do not touch boundaries) then making a 3rd party app to handle the code sharing and editing of the RS XML file should be easy. I don’t think RS would have to change anything. But this is speculation.

    In a nutshell I think we’re talking about editing some XML files and transferring it to others.

    When the new file comes in, there may be some simple things that need to be done such as:

    An autosave of the current project to get local coders code into the local XML file.
    A code update from the local file to the new proxy file, only updating the local coder’s code to the new file.
    Close the now unwanted RS XML file in the IDE.
    Auto launch the newly named RS XML file which contains the changes so it’s the active RS file in the IDE.

    OK, Just did a quick test (even though I haven’t had any coffee yet, FINE.) :

    I started a new project :

    In the IDE my code written from RS:

    // Coder ID:Sheppard
    dim xy as integer = 0
    dim thend as string
    // Coder ID:/Sheppard

    The ‘Sheppard’ and ‘/Sheppard’ would be used as the protection boundaries marking my code so no other coders could change my code because the control app respects my comment line protection ID’s since it knows who I am.

    The RS XML File:

    Sub Open()
    // Coder ID:Sheppard
    dim xy as integer = 0
    dim thend as string
    // Coder ID:/Sheppard

    End Sub

    Then I used TextWrangler to add new code (simulating the Xchange/editing app) to the RS XML file :

    dim thenewline as string=”Typed this up in TextWrangler”

    I next saved the new TextWrangler text file with a new name, then launched it and RS opened it with the new changes:

    Sub Open()
    // Coder ID:Sheppard
    dim xy as integer = 0
    dim thend as string
    dim thenewline as string=”Typed this up in TextWrangler”
    // Coder ID:/Sheppard

    End Sub

    I built and ran it fine in the IDE.

    There may be some small gremlins that creep-up but it seems pretty straight forward guys.

    If it’s something you guys need I’d think you could whip it up in a few days.

  9. The Real Studio XML format is NOT a good format for source code and version control systems. There is no guarantee of write order being consistent between saves.

  10. Not sure what you’re meaning?

    But each project file has a timestamp which could be synced by the server/transport app.

    If you mean addition data changes between the project files, that’s what you’re counting on updating to build the ‘active’ file to be used.

    Could be wrong but as long as the controlling app respects the other coder’s code it shouldn’t be a problem?

    What exactly do you foresee as an unsolvable problem?

  11. You’re off on a tangent. The whole point of the post is pointing out that sharing code between PROJECTS is not a great idea. It leads to too many issues.

    Sharing code between developers on a single project is done every day and is not a problem – at all. And in doing so we insist upon using the Real Studio version control format (VCP) and not XML. Version control format allows me to track changes down to the character, on a line, in every RS object.

    XML format is NOT ideal because the order that Real Studio saves the XML objects is not always consistent so the version control system will mark entire swathes of code as changed when in reality only the order changed.

    Again, we have zero problems sharing code between developers. The solution already exists in using Version Control Format and Subversion, CVS, Github or numerous others.

  12. This is also my experience. The use of external items also makes it very difficult to have reproducible builds over time.

Comments are closed.