Here's the requirement:
C# classes need to be shared among a group of 5 developers.
If one developer starts editing a class, it should be automatically locked for others
Others can edit that class, only when the current developer releases the class
I understand that Git is a distributed version control system, whereby complete local repositories are created. Merge functionality has to be used for creating a consolidated file.
I have also tried Svn, but even that uses a Merge tool.
I have a small team, and I don't want to use Merge Tools. Which is the best way to accomplish this?
SVN does support this kind of workflow with its locking feature.
Read the section on locking in the SVN Book v 1.7 - it goes into plenty of detail.
As far as Im aware git does not support a locking workflow.
Apparently Team Foundation Server also supports a locking workflow, but I'm not familiar with it.
I will add that i do not think this a good way to work unless you absolutely have to (eg binaries or hard to merge files like model xml). Regular team communication and defensive programming should mean that the vast majority of code merges will be handled automatically by your version control system.
Merging is just a part of collaborative development. Nobody really wants to use merge tools, but IMO having to do an occasional (sometimes messy) merge is a far better prospect that having to wait until someone else is finished with a file before I can make my change - changes which are very likely NOT to conflict with others changes anyway. Especially in a small team.
You should also not (as mentioned in comments above) need a resource dedicated to Merging. A merge is best done by two people.
The developer with the conflict, and
The developer who committed the last change (that has caused that conflict.)
If these two can't work it out pretty quickly, or you really do need a resource just for merging (which I have seen occur even in smallish teams of around 10 developers) you have problems.. such as;
The code is monolithic/highly coupled and needs refactoring
The developers are not committing atomic changes.
Using svn and a complex branching strategy (scary)
Developers are not talking to each other (Just a 10 min standup/day would help)
Good luck!
Apache Subversion 1.8 features major improvements that make merging and solving conflicts easier. New automatic merges are definitely worth testing!
As #mounds already mentioned, you can use pessimistic locking kind of workflow with Apache Subversion. See the SVNBook | Lock communication section. In such case Visual Studio with VisualSVN will prompt you to lock a file before you start modifying it.
Note that such approach should be used with those files that can't be merged. So~, Embrace Merge!
Users and administrators alike are encouraged to attach the
svn:needs-lock property to any file that cannot be contextually
merged. This is the primary technique for encouraging good locking
habits and preventing wasted effort.
Related
A brief note before I start: there is a lot of explanation required to "set the stage", and it may seem like this is more of a design question than a question about a programming problem. The question is actually about SVN branching and merging, so please read to the end.
Scenario:
I have a large Visual Studio solution with quite a few projects. I'm using SVN, so of course the trunk has my production line of development. This consists of a core DLL assembly, a "main" UI user client, and a handful of "plugin" assemblies that operate by implementing interfaces on the core assembly in order to provide functionality within the UI, and also by utilizing a set of service methods which provide common functionality to all of the plugins (such as persistence logic operations, storage operations for a centralized file store architecture, etc.)
There are also external utilities that I have built over time which must duplicate a lot of the business logic in the plugins. I won't go into much detail because it will ultimately distract from my main question, but just picture, for example, a scheduled service on a server that handles centralized maintenance operations related to a particular plugin's data.
When I initially built this application, I (stupidly) didn't anticipate the need for centralized service tiers, so I architected the core assembly (for better or worse), as shown above, to be tightly integrated with the presentation layer of the application. In other words, the UI presentation logic needed to integrate the plugins with the user interface and the business logic needed by the plugins to perform common plugin logic operations is all part of the one "core" assembly. Therefore, much of the "shared" logic that exists between the plugins and the centralized services has resulted in duplicated code.
I decided to undertake the major refactoring initiative to pull out the common logic -- that which is not related to the presentation -- into a "shared" assembly. For this, I created a branch off the trunk. I reorganized common code into a "shared" assembly, and I re-pointed everything in the client application (plugins, etc.) and the external service applications to utilize the shared assembly. In many cases, I also had to rename classes in order to fit their more-general purpose going forward. The core assembly remained in place only to broker presentation-layer responsibilities between the plugins and the UI.
Problem:
Now that I have successfully completed the refactoring, I want to reintegrate the branch back into the trunk. Merging is tricky business even in simple cases, but what I'm facing here is a lot of tree conflicts to put it mildly. Also, in addition to residing in an entirely new project, the folder structure in the "shared" project is quite a bit different from what it was in the "core" project. Classes are, in many cases, located in different places due to the new mechanisms for using the shared assembly.
I want to maintain the version history of every class from its old home in the core assembly to its new home in the shared assembly. Furthermore, I want to guarantee that the merge is successful. That seems obvious, but in testing a miniature version of this whole scenario, I was never able to get the conflicts to resolve in such a way where my branch features remained entirely intact. Furthermore, the fact that I have renamed some of the classes, as I stated earlier, to suit their more-general roles, makes it very tricky to maintain the version history.
I will note that I am using AnkhSVN which helps in "normal" cases when you rename files to repair the moves, but it doesn't seem to work in these major tree-conflict cases. Also, I know there is a difference in how merges work between different versions of SVN -- I believe it's pre-SVN 1.5 and post-SVN 1.5. I'm using SVN 1.9.3.
I have been trying to figure this out for a few weeks now. I've been pouring through the SVN book, TortoiseSVN resources like this, and anything I could find from google searches, like this, this, and this -- among many, many, many others. I feel like I'm going crazy and I think advanced SVN (and Tortoise) are impossible to learn with the traditional teach-yourself, learn-from-the-web-and-books approach. At any rate, I would greatly appreciate any insight that is out there.
What is the proper methodology when you create a feature branch using SVN and plan on making major tree changes and "moves" (i.e. renames) so that you can reintegrate those changes with the trunk without losing anything?
Congratulations to stepping on the most "popular" rake in SVN - "Merge Hell after refactoring"!
There are (at least) two simple rules for your case, produced by the bitter experience:
Never perform refactoring in SVN
If you'll ignore rule 1: in the name of all that is holy and good in the world don't touch ANYTHING in trunk during refactoring in branch
If you reject these the righteous covenants you still have a ways to salvation
Pure SVN-way, long and dirty
Merge all and every subtree, which is source of Tree Conflict, determining by hands every source and target like
svn merge NEW_PATH/NEW_NAME old_path/old_name
and finalize this the bloody work by full merge
Tricky Mercurial-way (or Git-way, but I just hate Git)
Preface: such merges aren't problem at all for modern DVCSes, they have "bridges" to SVN-repos, thus - you can delegate this job of merging to external VCS of choice and return results back (with some limitations and warnings)
I'm too lazy to speak about all DVCSes and will explain only about Mercurial (considering that with SVN-background it will be the least painful migration).
With HGSubversion Mercurial can read (pull) and write (push) to Subversion repositories, but - it can't push to Subversion results of it's own merges, thus: it will be multi-stage operation with the substitution of WC of Subversion in the process
A brief synopsis
Install Mercurial (TortoiseHG) and HGSubversion extension
Clone the whole SVN-repository to Mercurial into some temporary location (not current Subversion WC)
Merge branch to mainline (SVN's trunk become default branch), resolve (possible) context-conflicts (not tree)
Test (?) results
Perform the full replacement of Subversion Working Copy (WC of trunk, obviously) by the content of Mercurial Working Directory (beware of .svn and .hg folders respectively)
Commit WC to trunk
For the beauty and compliance with all rules "cheat" mergeinfo data of trunk (committed in step 6 must me known later as mergeset, although it is not true formally)
HTH
PS - migration to Mercurial with HGVS doesn't seems as totally crazy idea for now
We are using Tortoise svn as we have some issue we are going to move to VSS. Is Visual source safe comes along with VS2010 or should we buy separately and install. When we called and asked they said to select VSS from Tools->options->Sourcecontrol. If I do so I am getting some error as
As someone already answered on a comment, VSS does not come with VS2010.
In any case, I would strongly recommend against using VSS as your source control. It is several generations old technology as source control systems go.
It has serious drawbacks for the whole development process compared to the modern competition and should be generally avoided.
I have no idea what problems you have with SVN, but I would bet they are more of the organizational sort than technical.
From your comment I can infer that you expected SVN to give you same type of pessimistic locking workflow you had coming from VSS, but with SVN and other more modern tools, you have to change your expectations and workflow to a more natural parallel development.
In SVN you do not need to keep track of who changes what, as everyone can check out and modify every source file in the source tree and in most cases unless the developers change same lines in a same file simultaneously, the changes get merged together without any manual intervention whatsoever.
Instead of acquiring exclusive locks to a source file to modify it, you synchronize your local working copy before commiting it back to the repository and resolve any conflicts locally. This way nobody needs to keep track of who is working on what, just remember to update the working copy and resolve any odd conflicts before a commit.
Visual merge tools hep here tremendously.
Once you've converted, you'll love it and never want to go back.
If SVN does not work for you, there is a commercial tool called Vault by nice guys at SourceGear specifically designed as a replacement to VSS.
In case you feel especially adventurous and liberalized from the VSS, you might also take a look at the Veracity by same guys - a distributed version management tool much like the popular Git and Mercurial.
VSS does NOT come with VS2010 but you may still use it as a form of source control...although this is highly advised against.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Do you need a project management system if you work alone? I mean a project management system that includes issue tracking, wiki, etc.
Currently I keep my issues in a very good organizer software and I keep project documentation in Word files (and of course I have a version control system), so I am not really sure if I need a project management software, because I work alone.
One useful thing, I can think of, that project management system can additionally give me is linking issues with commits (UPDATE: I've found this feature useful enough: for example, right now I am creating documentation for the new release of my project and I consequently open every issue with "Pending for release" status, then I read the issue's description and then I can quickly view the diff of the commit for this issue - this helps me to see details and write better documentation).
Another one - sharing issues so your users or your employer can view or manage them.
What am I missing? Is project management software necessary when working as the only programmer?
UPDATE: I've thought up another useful thing: In comments we can give a link to an issue or a wiki article with detailed information about the code being commented.
You say you use some organizer software that helps you managing issues. So you already have your custom project management system. Just keep it.
Project management systems does not have to be big, support sharing data or other kinds of documentation. As a programmer you are supposed to use one to make your work organized, but it doesn't matter which one. You can happily use plain text files if they work for you.
Still, if there is even a slight chance that you'll be cooperating with someone, you should try something that allows cooperation... just to know how they work.
Do you need a project management system if you work alone?
Yes.
Currently I keep my issues in a very good organizer software and I keep project documentation in Word files (and of course I have a version control system).
See. You have a project management system. Why ask?
project management system can additionally give me is linking issues with commits.
That's not necessarily project management. You can easily do that with you version control software.
Read this: http://tortoisesvn.tigris.org/issuetrackers.html
sharing issues so your users or your employer can view or manage them.
That means you're not working alone, if you're sharing something. What are you asking for here? How to share?
When working alone is the key thought to pursue here. When you are alone, you don't have the luxury of having someone else to keep you on your toes. A good "system" is essential therefore in order to help you manage your projects. As to which system to employ, that all comes down to your individual needs, and how much time you want to spend maintaining such a system.
If there is any possibility that you will need to involve someone else, then you need to decide if the system you use will scale to meet your changing requirements. This is also true if you continue to work alone and your workload changes.
As for software, that is almost another question entirely. I personally prefer to use a software tool to track all of my tasks, and to help me to collate data that helps me to determine priorities and task scheduling. That is in a nutshell what project management is all about. When working at home on my own projects, I use a simple Redmine configuration to manage different types of projects. Planning for programming projects, working out the logistics for my wedding, even managing my house renovations. All have been added to my private Redmine setup because I'm too lazy to try and keep paper-diary styled systems updated. At work, I have a more complex configuration to manage the myriad of programming projects we have here, and to manage the dependencies between them.
I've found though, that the most important thing is to ensure that the processes are streamlined, and that the supporting tool can be configured to match the processes. You don't want to have to change your processes because the tool isn't up to par. Also, the tool should not become the sole focus of all of your efforts, therefore it should be configured to reduce the "red-tape" side of things. You only want to capture enough information to describe your tasks, and to determine when they need to be done, who will do them, and when they are completed. Yes, your needs may require more information to be captured, but always try to minimise this, as you don't want to feel like you are always updating your project management tool when you'd rather be working on that latest killer algorithm you've been looking forward to doing! ;-)
I would not want to work without a system like trac anymore, even if I'm the only one working on the project. You should use a version control system of course, no question about that. Then there are two or three things coming up, you also mentioned.
First is documentation. There are lots of different possibilities and a wiki is just one of it. I personally use the wiki mostly for ideas, thoughts and notes. It's easy to put drawings in it, link to ressources in the web and really quickly edit. This can not replace in code documentation you do with source comments or tools like doxygen. And this can also not replace a manual, if the project requires one.
The second thing you'll come across is some kind of todos, let it be bug reports (even from yourself), feature requests, things like that. You can put them as comments in your code or use a list in a text file or your PIM system, but you can also use a ticket system, just to keep track of what you want to or have to do in the project in the future. You can not do everything just now.
Third is the bigger plan, this is not just atomic todos but things trac calls milestones. This has to be written down somewhere.
The great thing about trac now is, you can integrate all these thing you have to do anyway in one tool and even cross link between all the parts. Link to code lines from a ticket, reference tickets in a commit message, use ressources from your repository in the wiki, automatically build doxygen and integrate it and so on. You must decide if you want to use trac for all the things around your project or something else, but you have these things anyway so why not use a system integrating it all? ;-)
I mean a project management system that includes issue tracking, wiki, etc.
I don't use an Issue Tracker, but I practice continuous (not "big bang") integration, and I test (look for bugs) early and often, and I fix any bugs as soon as I find them, so that list of known Issues remains small.
I also have a lot of structure in the source code (e.g. separate projects/assemblies for separate components), so I try to have "the code is the documentation".
The table at What Types of Documents Should You Create? implies that you may not need documentation (e.g. a wiki), unless you're working with other people: e.g. with a manager, testers, and/or end-users.
You may be the only programmer now but will it stay that way forever? I often work alone on development projects but I still track the "to do" list and issues in a simple Access database. Makes it much easier if you need to expand/hand over a project.
You absolutely do, at least for a bigger projects that take a few months. For the past years I tried :
eclipse notepad plugin - just text file - effective
eclipse mylyn tasks - better, enough for one-man-show, but I was still having issues with migration between eclipse instances
youtrack is free and it's like a JIRA but more simple and practical for an individualist
With notepad I was able to focus on current task, but I wasn't able to maintain long term iterations, because without issue tracker I was loosing discipline, dealing with 3 tasks at the same time, not finishing them, etc.
I've used source controls for a few years (if you count the Source Safe years), but am by no means an expert. We currently are using an older version of Sourcegear Vault. Our team currently uses a check out and lock model. I would rather switch to a update and merge model, but need to convince the other developers.
The reason the developers (not me) set up to work as check out and lock was due to renegade files. Our company works with a consulting firm to do much of our development work. Some years ago, long before my time here, they had the source control set up for update and merge. The consultants went to check in, but encountered a merge error. They then chose to work in a disconnected mode for months. When it was finally time to test the project, bugs galore appeared and it was discovered that the code bases were dramatically different. Weeks of work ended up having to be redone. So they went to check out and lock as the solution.
I don't like check out and lock, because it makes it very difficult for 2 or more people to work in the same project at the same time. Whenever you add a new file of any type or change a file's name, source control checks out the .csproj file. That prevents any other developers from adding/renaming files.
I considered making just the .csproj file as mergable, but the Sourcegear site says that this is a bad idea, because csproj is IDE auto-generated and that you cannot guarantee that two different VS generated files will produce the same code.
My friend (the other developer) tells me that the solution is to immediately check in your project. To me, the problem with this is that I may have a local copy that won't build and it could take time to get a build. It could be hours before I get the build working, which means that during that time, no one else would be able to create and rename files.
I counter that the correct solution is to switch to a mergable model. My answer to the "renegade files" issue is that it was an issue of poor programmer discipline and that you shouldn't use a weaker programmer choice as a fix for poor discipline; instead you should take action to fix the lack of programmer discipline.
So who's right? Is check in - check out a legitimate answer to the renegade file issue? Or does the .csproj issue far too big of a hassle for multiple developers? Or is Sourcegear wrong and that it should be ok to set the csproj file to update and merge?
The problem with update and merge that you guys ran into was rooted in a lack of communication between your group and the consulting group, and a lack of communication from the consulting group to your group as to what the problem was, and not necessarily a problem with the version control method itself. Ideally, the communication problem would need to be resolved first.
I think your technical analysis of the differences between the two version control methodologies is sound, and I agree that update/merge is better. But I think the real problem is in the communication to the people in your group(s), and how that becomes apparent in the use of version control, and whether the people in the groups are onboard/comfortable with the version control process you've selected. Note that as I say this, my own group at work is struggling through the exact same thing, only with Agile/SCRUM instead of VC. It's painful, it's annoying, it's frustrating, but the trick (I think) is in identifying the root problem and fixing it.
I think the solution here is in making sure that (whatever VC method is chosen) is communicated well to everyone, and that's the complicated part - you have to get not just your team on board with a particular VC technique, but also the consulting team. If someone on the consulting team isn't sure of how to perform a merge operation, well, try to train them. The key is to keep the communication open and clear so that problems can be resolved when they appear.
Use a proper source control system (svn, mercurial, git, ...)
If you are going to do a lot of branching, don't use anything less recent than svn 1.6. I'm guessing mercurial/git would be an even better solution, but I don't have too much hands-on-experience using those yet.
If people constantly are working on the same parts of the system, consider the system design. It indicates that each unit has too much responsibility.
Never, ever accept people to offline for more than a day or so. Exceptions to this rule should be extremely rare.
Talk to each other. Let the other developers know what your are working on.
Personally I would avoid having project files in my repository. But then again, I would never ever lock developers to one tool. Instead I would use a build system that generated project files/makefiles/whatever (CMake is my flavor for doing this).
EDIT: I think locking files is fixing the symptoms, not the disease. You will end up having developers doing nothing if this becomes a habit.
I have worked on successful projects with teams of 40+ developers using the update-and-merge model. The thing that makes this method work is frequent merges: the independent workers are continuously updating (merging down) changes from the repository, and everyone is frequently merging up their changes (as soon as they pass basic tests).
Merging frequently tends to mean that each merge is small, which helps a lot. Testing frequently, both on individual codebases and nightly checkouts from the repository, helps hugely.
We are using subversion with no check-in/check-out restrictions on any files in a highly parallel environment. I agree that the renegade files issue is a matter of discipline. Not using merge doesn't solve the underlying problem, what's preventing the developer from copying their own "fixed" copy of code over other people's updates?
Merge is a pita, but that can be minimized by checking in and updating your local copy early and often. I agree with you regarding breaking checkins, they are to be avoided. Updating your local copy with checked in changes on the other hand will force you to merge your changes in properly so that when you finally check-in things go smoothly.
With regards to .csproj files. They are just text, they are indeed mergeable if you spend the time to figure out how the file is structured, there are internal references that need to be maintained.
I don't believe any files that are required to build a project should be excluded from version control. How can you reliably rebuild or trace changes if portions of the project aren't recorded?
I am the development manager of a small company, only 3 programmers.
The projects we work on sometimes take weeks and we employ the big bang, shock and awe implementation style. This means that we have lots of database changes and program changes that have to work perfectly on the night that we implement. We checkout a program, change it and set it aside because implementing it before everything else will make 20 other things blow up. I am for check out and lock. Otherwise, another person might change a few things not realizing that program has had massive changes already. And the merge only helps if you haven't made database changes or changes to other systems not under source control. (Microsoft CRM, basically any packaged software that is extensible through configuration)
IMO, project files such as .csproj should not be part of the versioning system, since they aren't source really.
They also almost certainly are not mergeable.
We use Subversion as our source control system and store the VisualStudio project files (vcproj) in the source control system as is normal I think. With Subversion we don't use any form of file locking, so if two developers are working on the same project at the same time and both add files to the project, or change settings, the second one to commit has to merge the changes.
How do you merge these changes?
The vcproj files are just text files so it is possible to edit them by hand but they are not very amenable to hand editing, especially by junior developers.
The ways I can think of are
Get the latest version from svn and re-add all local changes manually
Edit the file by hand to resolve any conflicts from an automatic merge
Implement some form of locking scheme to prevent simultaneous changes
Have an agreement between developers so they do not make simultaneous changes
Currently we are using the first option of re-adding all changes manually but this is time consuming and I was wondering if there is a better way.
With source files the automatic merge feature works most of the time and we don't get many conflicts.
I've found that option 2 (edit the files by hand) generally works fairly well, as long as you're using a good diff tool (I use WinMerge). The main problem I've run into is that Visual Studio will sometimes reorder the file. But, if you have a good diff/merge tool then it should be able to differentiate between changed content and moved content. That can help a lot.
You might find Project: Merge or Tools for SLN file useful
This is a tough problem and I think a weakness in the Visual Studio architecture. The way we found round it was to not have the proj files in source control at all and to have a build script that handled the configuration settings.
The alternative was very messy and we could not guarantee consistent builds or environments between developers. This led to a huge number of downstream integration problems and eventually we took the draconian step of removing the project files from source control.
The developers environments could still become misaligned but it showed up when they tried to build things themselves.
Using TFS here, but I don't think it makes a difference.
We also don't lock, and sometimes have to deal with merging project files. I've never found it to be that complex or much of an issue. Rarely do we ever experience issues that can't be merged automatically, and the manual merge process is pretty much trivial.
There's only one caveat to this: Check in often! If you make major changes to the project structure and don't check them in immediately those changes can start compounding the complexity of later merges. If I make a major change to the structure of a project, I usually give everybody a heads up. I'll ask them all to check in their current work, and then take care of the merge myself.
I found this recently: http://www.codeproject.com/KB/macros/vcproj_formatter.aspx
If you run this tool on a vcproj file and on a modified version of it then you can merge them together easily with your favorite text merge tool, and in addition the result is a more compact pretty vcproj file.
Options 1 and 2 are not mutually exclusive - if the developer is junior level, let them use option 1 (re-get the project file and re-do the changes) if that's more comfortable for them. For more senior developers, option 2 (merge using a merge tool) is perfectly fine.
I think this is a situation that currently has no magic bullet - sometimes merging is a pain.
We use a diff tool (WinMerge) to merge changes. The project files are (for the most part) really straight-forward XML. The key here, though, is that there never should be any surprises when merging, because good communication is part of the bed-rock of effective source control.
Simultaneous changes to the project are perfectly fine as long as people communicate.