Tag Info

Hot answers tagged

59

If I was going to look at upgrading to a newer version of a third party SDK, the last place I'd look is in the history of the source control system. If your product is using version 2.0 of an SDK and someone is interested in upgrading to 3.0, I don't think it's reasonable to think that they should look backwards in time in your source control system to ...


35

All code is temporary. When I'm making changes I will introduce placeholders occasionally - that icon that I drew waiting for the real one from the designer, the function I know will call the library that my colleague is writing and hasn't yet finished (or started), the extra logging that will be removed or otherwise made conditional, the bugs that I will ...


20

Critical and non-intuitive pieces of information should be documented where people will be looking when considering the information. For the teams and projects I've worked on, I would commit the roll-back with the comment about why the new version failed. I would add a backlog story to re-try the upgrade if the new version get's fixed. I would add comments ...


17

It should be noted in the commit history but the absolute best place to put the notice is in the same place you define the dependency. If you have for example a maven .pom file that declares your artifact dependencies, I'd do something like: <!-- Do not change the SDK version because it causes Foo crashes. For more detail see Issue #123 --> Directly ...


11

Project files. Paths may need to be edited in order to reflect the layout on the current PC. For project files, the best strategy is when you can generate the project file via a script. Add the actual project file to your ignores, and simply re-generate the project file as necessary. For example, in Java projects, I use gradle which can generate an ...


10

I'm not sure how your team communicates but I believe the most effective way to say this is to first send and email to the team's email group, marked as "URGENT" with the body saying Guys, we can't use SDK v x.y.z because it causes the Foo buffer to overflow and the Bar service will crash. Stick with version x.y.y That's what we've done here and it's ...


6

I'm recasting the question as "Should I communicate critical information I discover to the rest of the team only via commit message?" Because I think that makes it obvious that no, you shouldn't. I try hard to communicate a lot (this is something that most development teams, in my experience, need to put active effort into) and I certainly do everything I ...


6

If it is just a single JAR file, then I don't think version controlling it will be apocalyptic. If however, you start adding more and more external JAR files to your app, then you should consider using a repo manager like artifactory to deal with this whether you opt to use Gradle/Maven/ANT. If you have a build script, you can further simplify the task ...


5

You can create separate Git repositories for each library, publish them, then use Git submodules to link them to the main repository. git submodule add submodule1_url directory1 git submodule add submodule2_url directory2 git commit -m "add submodules" Working with submodules is a little more complex. After cloning the repo, you need to clone the ...


4

It should be in the commit history but it should not only be in the commit history, imagine for a moment you hire a new developer. Do you expect that new developer to read every commit message for the past 10 years of your project because a couple of them will be critical to understanding your code base? Second say the situation but not the code changes, ...


4

Version control should contain code and configuration which is needed to build the application. This means that: Temporary stuff which was introduced for a short amount of time (the time required to pinpoint the location of a bug, or to experiment with a feature of a language, for example) shouldn't be in a version control: keep it until you need it, then ...


3

Something like this should have been put in the commit comments, but it will benefit from being in other places as well. Whoever makes the decision to upgrade, needs to have the facts. That person may not live in source control. What if someone would have read about this problem on SO and never put it into the code base? There needs to be some sort of ...


3

I think you'll find all SCMs are roughly the same, though you could consider Visual Sourcesafe as an esoteric outlier :-) Nearly all work on diff deltas between commits, SVN for example has the same kind of diff+patch approach darcs does, only it doesn't try to pull in more revision history than you ask it to when merging (I'm not sure if Darcs trying to ...


3

I've seen this feature as well, and am also wary of it. If I were to articulate my reasoning, I would say that it muddies the cleanness and intent of a commit message. When I ask myself, "what is the intent of a commit message?", it is to act as a succint breadcrumb to myself and others about what I was working on and how I tried to make it better. To that ...


2

We use @@ comments in the code to indicate anything not being quite ready, for testing purposes, etc. That way we can commit, colleagues don't have to wait too long to sync, and can see where there's still work in progress (e.g. understand why a part is not yet fully working). We do a global search for @@ to prevent any 'leftovers' before entering the ...


2

What you're essentially referring to is a platform. While I see that it is used to "push off" from a certain project skeleton, with a little work, you can turn this into a platform library. The advantages are that you can simply update the library to apply the changes to any project you're working on, and any project that is better left untouched can stay ...


2

My experience is with CVS and laterly Subversion, so someone else will need to cover the more modern distributed systems like Git and Mecurial. Your first question (source.c) is probably better fixed by putting common code into libraries, then linking the libraries into multiple products. That way there is only a single source file to change. SVN does ...


2

Since the maintenance page is a feature of the web application, there is no reason to put it into a separate branch or repository. Instead, have a dedicated directory, or maybe even just a file at the root. This will make it possible to: Share all static files such as the images, CSS or JavaScript, Benefit from common code instead of duplicating it with ...


1

There are approaches within svn (and another approach). Other tools such as git will handle a symbolic link (and more info). It is fairly common for various version control systems to have some way of handling symbolic links (perforce, hg as two more). At this point it becomes a question of how you want to structure your code. All that said, I'm going to ...


1

Fossil and Veracity are two VCSs that are not just VCSs, they are full project management systems. In addition to VCS functionality, they also include bug tracking and documentation, among other things. Veracity specifically is based around the idea that there are two general "shapes" of data in project management: "file shape" (a tree of unstructured, ...


1

Image-based systems such as most Smalltalks, LISPs, but also the Intentional Domain Workbench and similar tools have VCSs that aren't based on text. In those systems, programs aren't text files, they are semantic graphs of rich objects. In image-based systems, "programming" actually means "mutating the live running program while it is executing". Their VCSs ...


1

2 HAMSTER solutions: You can use a pre-commit hook to check your code for some unusual keyword like HAMSTER. Just don't let people commit code that has been HAMSTERed and use it whenever you do dirty hacks. Another option for example in C is to use #ifdef HAMSTER, then the code will only run on your machine where you have a compiler flag HAMSTER.


1

Currently Debian provides the integration via git-remote-bzr package, which lists as it's homepage https://github.com/felipec/git-remote-bzr.



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