What would work best?

fenris
fenris
Hi all, I am new to the forums and I hope you guys can give me some pointers. I am using subversion (on a linux server) with my development boxes running windows XP using the tortise clients. I really like the way that this system works. I develop plugins for a product called AutoCAD (a drafting package). I am having a bit of a conceptual issue. I have been developing a plugin package for AutoCAD 2000 (I know it's a few years old, but that's what the client wanted it for). We have another customer who wants the program for AutoCAD 2005 (the latest incarnation). I checked it out and the only difference that my code would require is that the reference to the object type library be changed - nothing else.    I was wondering what the best strategy would be to store this "new" version in subversion?    Currently I have this:    AutoCAD 2000/v2.9   /Branches   /Tags   /Trunk   /all my working code is stored here    I would like to have a similar structure except the root would be called "AutoCAD 2005". But doing it this way would lead to a large duplication in effort as both branches would have to be modified seperately. I would like changes in one to be reflected in the other, if that is possible?    Thanks.

Last updated

Troublegum
Troublegum
You could use branches.  trunk/ would contain you newest development line - meaning your autocad2005 plugin  Then you create a copy of trunk/ in branches/autocad-2000/ and change the link to your library in branches/autocad-2000/    If you're implementing something in your autocad2005 plugin and you want it to be in the 2000 branch as well, you can merge the changes into you branch with the following commands. Assuming revision X was the change you want also to have in the 2000 branch. Then X - 1 is the Revision before. Let's say Revision 100 and 99.  cd branches/autocad-2000  svn merge -r 99:100 http://svn.example.com/repository/trunk  svn commit -m "merged r99-100 from trunk/ into branches/autocad-2000/"
fenris
fenris
Troublegum, thanks for the reply. Lets see if I understand. I would create a branch for my acad2000 development line:    /Branch/acad2000/      I would make the changes in the trunk so that the plugin could work for 2005. Now if I made changes in the trunk that needed to be in the 2000 version I would simply merge the changes from the trunk to the branch. Now, how do I tell subversion not to merge specific files, but everything else should be merged. In my case I am using visual basic and the .vbp files contain the references to the various com components.    Is this line of reasoning correct?
Troublegum
Troublegum
fenrisI would make the changes in the trunk so that the plugin could work for 2005. Now if I made changes in the trunk that needed to be in the 2000 version I would simply merge the changes from the trunk to the branch.[/quote]  Yes, that was my suggestion.    [quote=fenris]Now, how do I tell subversion not to merge specific files, but everything else should be merged.
 I am not sure what's the best way to accomplish that.  According to the refernce svn merge does not accept a simple filename as target parameter, but only a path to your working copy.    Say you modified fileA and fileB in your trunk in ONE commit and you want to merge the changes in fileA into your branch but not the changes in fileB - that would be a little bit tricky. You could try (not tested!) this?  cd branches/autocad-2000  svn merge -r 99:100 http://svn.example.com/repository/trunk  svn revert fileB  svn commit -m "merged r99-100 from trunk/ into branches/autocad-2000/"    That would theoretically merge the changes between revision99 and revision100 from your trunk into your branch, except that fileB is not changed. svn reverts fileB should undo all local changes to fileB which where done by svn merge.
k-dub
k-dub
fenrisI would make the changes in the trunk so that the plugin could work for 2005. Now if I made changes in the trunk that needed to be in the 2000 version I would simply merge the changes from the trunk to the branch.
   I believe this would cause problems. Wouldn't you want to work on the 2000 version on the branch? This might be easier if you use two working copies, one from the branch and one from the trunk. If you try to do both on the trunk, each change will be stepping on the other, thus the need for a branch.
fenris
fenris
Thanks for all the replies. I have been thinking about the pros and cons and I think I will make an entirely separate branch for the acad 2005 version. It might be a pain to have to make changes to both versions, but I am pretty sure that acad 2005 supports more features then did its predecessor. Also the acad 2000 isn't officially supported anymore, but our biggest client hasn't made the switch to the newer version of the software yet.    Thanks all for your helpful replies! They were greatly appreciated.

1-6 of 6

Reply to this discussion

You cannot edit posts or make replies: You should be logged in before you can post.