Tag Info

Hot answers tagged

44

You almost certainly want a new repository. The purpose of the repository is: to track history and changes so you can compare them easily to manage branches and merges rather than just emailing patch files around and applying them to working directories manually If you're totally rewriting a project from scratch then there is no point putting the ...


23

I think this discussion pivots around a few things, not solely on the TODOs in the comments of the code - but they how are used and what they are used for to begin with. Code checkins If you are using private working branches, then checking in code that has odd temporary comments and markers as personal pointers of your own thoughts may not be so bad ...


16

I always put rewrites in new repositories myself. That way the builds, tests, and deployments can all be done independently. When you're rewriting a project in another language there's often very little similarity in any of those tasks like building, running tests, and deploying. You'll save yourself pain if you just isolate them in their own repository. ...


10

To begin with “TODO” seems great... Then people starts to check code in with them. Then after a few years, the checked in code has 1000s of “TODO” in it. At that point, they become worthless, as you can’t use a TODO to track own work in process in any code. Hence the common rule about not checking in TODOs into branches that are meant to contain ...


9

Since the history is preserved in version control, there is absolutely no reason not to remove code you don't need. By the way, this applies as well to commented code within the source: don't comment blocks of code, just remove them; if you'll need them later, version control is your friend. Later may be even in an hour. The common sense may dictate that if ...


7

No, not a good idea. Source Control is named that way because it contains source, not the compiled result, or test output in your example. Test logs are temporary files that are used only to debug tests, and thus should not be present in the source control.


5

If your systems are sufficiently modular and link compatible, you would benefit from a single repository and build. For example, if C system is being rewritten in C++, the C++ code could call existing functionality and incrementally replace it. However, even in this case some might argue for starting a new repo in which relevant old code is pulled in as ...


4

I'm very sceptical about TODOs. I think all too often they serve as a label that helps to pass procrastination as some sort of a disciplined approach. Therefore I'm inclined to side with your team and I'd advocate to refrain from using them other than solely for private use, which is nobody's business of course. It's all good and well in theory, but as ...


4

The problem with deleting is that they are "out of sight" and therefore "out of mind". The problem with archiving is that links or relative references will no longer apply. Tricky... Personally I would delete them, and tag the revisions that these were deleted. This allows the dead projects to be easily retrieved, in place, yet also be hidden but still ...


4

Each branch has a role. Branching for a feature is a good one as it allows the feature branch to specifically identify that role. Always merging back to default implies that default is the roles of mainline, accumulation, and packaging - and this is where you are having trouble. You should instead consider making a branch for the role of 'accumulation for ...


3

I think that your workflow of writing a feature (or a bug fix) and then committing it to the "default" (which appears to be a main or trunk branch) is the problem. Instead, consider using an alternative branching strategy. I'm typically only focusing on one release at a time, so there's an "integration" branch off of the trunk and then there are development ...


3

Ask for meaningful commit messages The problem does not come from using merge commits instead of rebase in this particular case. It is the lack of meaningful commit messages. For example, without seeing your repository, this could very well be a merge commit: Ron Cosby PROJ-15711: Fix the jsdoc template But contrary to the other commits, this one ...


2

When I use TODOs (and FIXMEs), I tend to write them as questions, rather than statements. For example: // TODO: Can we ignore the negative case? // TODO: Is this premature optimisation? // FIXME: Is there a more robust alternative to parsing the version number? // TODO: Is it worth extracting this to a separate module? There are a few reasons for this: ...


2

Can you recall a situation where a good commit message saved you at least 3 hours? Yes, absolutely I can! Properly written commit message will have keywords of major changes to the system. SO you could glance on it and know exactly that's the commit you need. We once had a defect that was originating from changes(we have 24 people team, so good luck ...


1

One way of 'hiding' the merge change sets is to use Mercurial Queues. It is an extension currently being distributed along with Mercurial. In short, they are mutable change sets, known as patches in a patch-queue. Instead of having to merge, your users can rebase and then apply the patch or patches they want to push on top of the tip of the rebase, ...


1

One (common) way of solving your problem is with the use of branches, as described by the other answers. However, there is another solution: feature toggles (aka. feature flags). The basic idea is that your program maintains a list of flags (the feature flags) that can be switched on and off, and the code that implements the feature checks its ...



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