I'm not really sure about the locking solution. First of all, you'd also have to enable the svn:needs-lock property on your project files for this to work properly.
Keep in mind that in most cases, subversion will be able to merge the changes automatically. In this case you ran into problems because you're working in a sample project, and you added a file for which the references in the project file ended up right next to each other, causing the automatic merge algorithm to fail. In practice you won't get in this situation very often (ask yourself: what are the odds of you and your colleague adding a similarly named file in the same subfolder of the same solution project?) For the rare cases where you do get into trouble, I think simply resolving the conflict (outside Visual Studio, either by hand, or through TortoiseSVN) is perfectly feasible. Locking would work too, but will seriously hinder collaborative development (you won't be able to both add files to the same solution anymore) just my .02€ jeroen On Apr 6, 5:11 pm, Chris Jordan <[email protected]> wrote: > Jeroen, > > I think you might be right. What we've decided to do (and please let me know > if this sounds like a good plan) is whenever one of us want's to ADD files > to the project (new modules, new forms, whatever) we'll get a lock on the > .vbproj file, add our file, and then commit (adding the file to the > repository and releasing the lock). This seems to have worked for us in our > small tests. > > Thanks for the link to book. I did manage to find that on my own after > having written to the group, but I've not had the chance to read it yet. > > Cheers! And thanks for your help! :o) > > > > On Sun, Apr 5, 2009 at 6:41 PM, jeroen <[email protected]> wrote: > > > I suspect this is what happens: > > > When your colleage updates his solution, subversion marks the project > > file (.vbproj) as conflicted. (This vbproj file is a plain text/xml > > file). Marking the file as conflicted (with the default conflict > > markers, just like any other text-based file) will cause the file to > > be invalid for Visual Studio. VisualSVN (to my knowledge) does not > > explicitly cope with this situation. > > > So you have to resolve the conflict manually, outside of visual > > studio. You can do this manually by simply editing the file in > > notepad, or through Windows Explorer with TortoiseSVN. > > > You might want to read up on manual conflict handling in the > > subversion book: > >http://svnbook.red-bean.com/en/1.5/svn.tour.cycle.html#svn.tour.cycle... > > > greetz, > > jeroen > > > On Apr 3, 8:58 pm, Chris Jordan <[email protected]> wrote: > > > Hi, > > > > A co-worker and I are experimenting with VisualSVN on a VB.NET using > > > Visual Studio 2005. He's been using the SVN by himself for a little > > > while now, but now that I've joined the project, we're trying to > > > figure out how we need to do our day to day tasks. > > > > Our first experiments were with the both of us working on the same > > > file. We think we figured out that the best thing to do was to obtain > > > a lock on the file we need to work on so we can avoid having to merge > > > two versions of the same file together. fine. > > > > So our next experiment is what has us stumped a bit. > > > > I added a module to the solution (module1.vb) and he added module2.vb > > > to the same solution (our working copies of course). I committed my > > > changes (the adding of module1.vb) and all is fine. He then goes to > > > commit his change (the adding of module2.vb) and the solution freaks > > > out, says there's a conflict and he can't view any of the files in the > > > solution. If he clicks revert changes and checks the box for the > > > solution file, he is then able to reload the project and see > > > everything again, but the module he was trying to add is now gone > > > (meaning it's not a part of the project anymore). > > > > What the heck are we doing wrong? We're going to keep searching the > > > internet and any manual stuff we can locate, but I was hoping that > > > this group could help quickly point us in the right direction. > > > > Chris > > --http://cjordan.us
