Subversion SCC and reusable code

[BertMcMahan]

Thanks everyone for all of the responses. I've been busy this week just trying to get the core SVN "experience" going, which has gone well so far.

It sounds like I have a couple of options, the first being to use SVN externals- which I don't understand yet and will need to read up on, or to use VIPM. VIPM Pro is going to be a no-go for right now for cost reasons, but my dependencies aren't super complicated at the moment.

I'm having a bit of trouble wrapping my head around the packages and how they're handled in source control. Let me see if I can sum up what I'd need to do- and please correct me if I'm wrong. I have only had experience using VIPM for downloading random packages from the internet, so I'm not totally sure I have a handle on how packages work in practice. Let me know if the following sounds correct:

-Have my reuse library in its own repo. When I have a version ready to use, I make a tag, and generate a package using VIPM. This generates a single file (a package) containing the reuse code at that point in development.

-This package file goes into the _project_ repo, and is maintained as part of the project. When I'm finished with the project, I can uninstall that package if I want, but the package file itself is committed along with the project source code into the project repository.

-Later I need to do some edits to the project, and the reuse library has "moved on" to newer versions. I can simply roll back my main project repo and install the package saved there and do the bug fix/upgrades/whatever. At this point I don't look at the shared code repo, only at the VIPM-generated package file stored with my project repo.

Does that sound right? I'm going to read up on SVN externals, which initially sounds like I can access multiple repositories at once, is that right? If so- can I do different commits to each repo, or only in my main one?

[wiebe@CARYA]

With externals, you can mark files\dirs in you're repo as early. To this means you can choose to update\commit\revert\etc. this repo independently form he 'main' repo. I don't think it's more then that. The external repo files still end up in he main repo, so you will have all revision history and 100% certency you can revert to a previous revision. If a driver is in vi.lib or user.lib, you don't have this certency.

I'll repeat this advise. You can live with ignoring this issue. Simply copy libs. There will be no link to the lib repo and he project repo. I understand it's not ideal, but it's no big deal. You can consider it the icing on the cake.