Hot answers tagged

177

You can loosely replicate the role source control plays with three simple tools: Back-up software (Commits/Check-ins) Folders (Branches) Performing a directory merge between two directories using a tool like KDiff3 (Merging branches) Basically your workflow becomes: Create a new folder (new branch) Copy files to the new folder (new branch) from an ...


139

Although the consensus would certainly be to not work for this company I don't believe that really answers your question. You can't really replace SCM. You might not need the usual bells and whistles of a full-blown system. For example, the company may refuse a request for a server, but permit the use of a local SCM. They may dislike git, but permit ...


110

The problem with adding a comment to a file that it should be deleted, instead of deleting it in source control and putting the explanation there, is the assumption that if developers do not read commit messages that they will surely read comments in source code. From an outsider's perspective, this methodology seems to be rooted in a very conservative view ...


105

Yes it is bad practice. You should put the explanation for the deletion in the commit message when you commit the deletion of the files. Comments in source files should explain the code as it currently looks. Commit messages should explain why the changes in the commit were made, so the commit history on the file explains its history. Writing comments ...


61

Some suggestions: There is nothing wrong in having a lot of feature or bugfix branches as long as the changes done in each branch are small enough you can still handle the resulting merge conflicts in an effective manner. That should be your criterion if your way of working is ok, not some MSDN article. Whenever a branch is merged into trunk, the trunk ...


58

There are several problems when commits are directly pushed to master If you push a work-in-progress state to remote, the master is potentially broken If another developer starts work for a new feature from master, she starts with a potentially broken state. This slows down development Different features/bugfixes are not isolated, so that the complexity of ...


47

You're looking for a technical solution to a human problem. That rarely works. The reason for that is because if team members do not accept something (nor understand the implications), instead of following the rules, they'll attempt to circumvent them. That's exactly why, for example, developers should accept and understand style rules instead of just being ...


25

Basically, there is a management problem (your organization don't understand the basics of software development process, e.g. the V-model) condensing into the apparent inability of using minimal present-era workflow, methodology, and tools. This is common (read about Peter's principle). BTW, I guess that recent SNCF railway incident in Paris at end of 2017 ...


23

There is nothing too difficult about SVN merging... anymore... if you follow the right philosophy What I see in most other answers seems to come from people who haven't used SVN in a while. As someone accurately mentions: "it wasn't fixed early enough to dispel the myth". From my current experience of using SVN 1.6 to 1.8 on a legacy project I inherited ...


19

Why would it be a problem over having trunk and branches? A tag is just another branch, but (and perhaps this is the important bit) you do not have to checkout the entire SVN repo. Instead of calling svn co http://repo/ call svn co http://repo/trunk Then, if you want to see a particular branch use svn switch. Everyone I know who uses the trunk/tags/...


18

Are we exhibiting the very anti-pattern that was described as the 'big bang merge'? Sounds like it. Are some of the problems we're seeing a result of this merge process? Definitely How can we improve this merge process without increasing the bottleneck on my boss? At my company, every dev has the ability to merge. We assign a Merge Request to ...


15

It works fine if you stick to the simple cases, but there are some complex ones that don't. The limitations I can think of: It can only find the most recent ancestor if it is on one of the branches involved. So if you create branches/this and branches/that both from trunk and then try to merge branches/this to branches/that, it will not know what to do. ...


15

In my opinion both of your options are not best practice, as opposed to bad, practice: Adding comments only adds any value if someone happens to read those comments. Simply deleting from the VCS, (with a reason in the change description), may impact a critical deliverable and many people don't read the change description, especially when under pressure. My ...


13

One basic rule of source control is that you need only to put manual written artifacts into the repo (the original source files), everything which can be "compiled" or "generated" does not need to be stored there, because it will produce redundancy. One can (optionally) store intermediate outputs/parts of a build process in a repo (sometimes also called ...


13

This is essentially how a lot of open source projects work, including most notably the Linux kernel, which has a lot more branches in flight than you do at any given time. The typical way to avoid big bang merges in these projects is to create another branch (or multiple branches) for continuous integration. This is the branch you use to make sure your ...


12

Why don't you use git locally to share your code with your three development machines/environments, and then just use SVN to do the commits that go to the rest of your development team. This way, you can use git without locally without making the rest of your team use it.


12

You should create a new repo for each independent project. Why? Someone working on project D does not have to download all the history for E and F. Git repos are cheap to initialize, so you can use as many as you like. It is painful to work with multiple projects at once when they are represented as branches in a repo: When switching from A to B to quickly ...


12

Wow, that's a long question (and a complex problem). I'll try to have a go at it. I'm not sure I understand why each user has to have a full local history when using git? This is a central design decision with git. For the exact reasons you'd need to ask the author (Linus Torvalds), but as far as I know, the main reason is speed: Having everything ...


12

Explain to him that new features need their own development branch that can be deployed to a test environment before it is pushed to production. Otherwise, you're in a perpetual state of half-completed features. You can't deploy half-completed features to production, so if you're working directly on the master branch, everyone else must wait for you to ...


11

First thing I would do is identify specifically what the government agency (presumably the IT department) is objecting to. If they have storage space, but no way of hosting VMs for servers, then the problem may be that the IT department is saying no to the SVN or GIT server and that is a big distinction. If the problem is the country of origination--i.e. ...


9

The Git Flow assumes you only have a single supported release, with the master branch always pointing to the latest release. Since you support multiple releases simultaneously, you cannot copy that workflow 1:1. Nvie's Git Flow is a very good example of a branching strategy, but you must adapt it to your needs. Most importantly, you will have multiple active ...


9

Given the constraints you mention in the comments (e.g.: can't get to Git download page, Windows platform, and using Visual Studio 2005), I can see 2 options, both of which I have used before in a similar situation: Use Visual SourceSafe as Emerson suggests in a comment. I worked with a team using VS 2005 some years ago, while most of the rest of the ...


9

First, I just want to say I don't understand why you are migrating if they don't want to use git like git. I agree with you that it's workable, and it's not even that problematic to split it up later. You would basically just duplicate the monorepo and delete the branches you don't want in each copy. The main concern I would have is dealing with the ...


8

Unfortunately this is not supported directly by Subversion prior to Subversion 1.8. The files in the branch and the files in trunk are copies and Subversion keeps track with svn log only for specific files, not across branches. So the only option is to filter your SVN log. The major downside to this is that in case you filter for file name, files being ...


8

I think it all depends on how the branches are structured. 1. Branch A and branch B are independent branch A +---------+------------- / \ merge 1 trunk ------+--+----------+--+-------- \ \ merge 2 branch B +-------------+------ As you can see here, I would merge from branch A to trunk, then ...


8

The canonical reference is the Subversion RedBook. Regardless of your past skills, read this from fresh and you'll get all the usage information you need. Its not difficult or completely alien, most people say SVN is a lot easier to understand than git so you should be fine with just a little bit of reading the main commands. The basic usage chapter should ...


8

Setup a Maven repository and manage your dependencies with Maven or Ivy. Maven seems to have more market and is a more complete tool for builds. Its main downside is that it relies in convention, which makes it very simple to use if you adapt to it but more complicated if you want to do things any other way. Ivy only manages dependencies, but you can make ...


8

They have tons of storage space Are you allowed to use it at your on decision? If so you could create a file system remote repository which is better than nothing. The downside is that pushing becomes slow while the project is growing because git needs to download the whole repository to look for the changes... so far the computers behave like ordinary ...


Only top voted, non community-wiki answers of a minimum length are eligible