Jim, I think you can accomplish both goals you are looking to achieve.
First, correct me if I am wrong but if I understand correctly, are you saying you just want to be able to check out parts of a repo multiple times (to have multiple branches checked out at the same time)? If so, Git lets you do a sparse checkout so you should be able to clone the repo multiple times but only check out certain subprojects if you want. https://git-scm.com/docs/git-read-tree . So if you wanted to just check out 3 different versions you could clone the repository 3 separate times but do a sparse checkout to only grab certain subdirectories to save space. Second, as far as generating unique builds I think you could accomplish this by using "lightweight tags". A lightweight tag in git simply is a pointer to a specifc commit and would conceptually be very similar to assigning it a unique number based on an SVN commit. There's almost no overhead to creating a lightweight tag in git, it just stores the commit checksum. https://git-scm.com/book/en/v2/Git-Basics-Tagging Creating a lightweight tag for every build could be automated and would allow you to go back to a unique build for every commit. Chris On Tue, Feb 21, 2017 at 9:27 PM, Clebert Suconic <[email protected]> wrote: > > So, that's a "Yes, it does duplicate the entire repository (which can be > > quite sizeable) in order to have multiple branches checked out > > simultaneously." Got it. Clearly a disadvantage. > > I give up!!! > We should probably migrate Artemis and AMQ5 to SVN as well. > Pretty horrible disadvantage to have all the versions available > without being connected. > > You can certainly do tricks to checkout on another directory, but it's > just easy to copy the directory. > > > So, for example, I would be able to have the following structure on my > > local hard disk? > > > > Apache.NMS/ > > /trunk > > /tags > > /1.7.0 > > /1.7.1 > > Apache.NMS.ActiveMQ/ > > /trunk > > /tags > > /1.7.0 > > /1.7.1 > > /1.7.2 > > > That's messed up... horrible dependencies between versions. Even as is now. > > I wouldn't even bring that build style into the new project. If that's > the case I would say keep the current SVN the way it is, and start a > new one on git. >
