Tag Info

New answers tagged

0

Expanding on Karl's answer, I would go with an approach that automatically enforces the restriction as part of the checkin process itself. You need something that does not require any proactive action on behalf of the developer, such as reading a doc/wiki/README, and can not be overridden covertly. In TFS source control land you can code custom checkin ...


3

I wanted to give Matthew's comment more attention by highlighting his important idea in an answer. There's a reason why you don't want to upgrade your SDK, and that reason should be captured in a unit test. Not a check for a revision number, but the actual underlying reason. For example, say there's a bug in the new version. Write a unit test that checks ...


1

I interpret this situation as having two basic problems, possibly three. An unwanted SDK upgrade made it into the source, where it could negatively affect the product. From the question: the contributor who performed the unwanted upgrade didn't know about a previous, specific decision not to upgrade. The first of these, in my opinion, is the most ...


0

I would say adding that type of information to a commit history is ok but it still needs to be documented properly. We recently started using confluence (by atlassian). Its searchable, you can set certain pages as favorites, etc. Some other tools might be a public notebook in evernote or google docs.


1

History is a great place to put data intended for a reader who is consciously looking for it, and has a general sense of where it should be. It is a very bad place to put data which must be proffered to a user, rather than searched for. Histories are very large bodies of relatively unsorted text. They are usually intended to provide a developer with ...


13

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 ...


35

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 ...


8

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, ...


29

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 ...


92

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 ...


5

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 ...


9

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 ...


1

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


0

As MainMa already said, the maintenance page is a feature of the site. They are not two sites. The maintenance page is a special page of the site and should therefore go with it in the same tree. Branches are great for parallel history, but not suitable for about anything else. For different variants, the only practical way is having them together in the ...


3

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 ...


0

It is never harmful to put code in source control. Every single one of the items you mention should be in source control.


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 ...


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 ...


0

Actually, git is rather different from the concept you described. In a nutshell, this is how it works: It's repository stores compressed copies of entire files that have changed, as determined by the SHA-1 hash of the file, rather than some form of a diff patch. But if the hash for a file is already anywhere in the repository, even if found on some ...


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 ...


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 ...


0

I believe that some systems will throw warnings on seeing TODO in a comment, so // TODO: remove this hack. might be all that is necessary if you can find a relevant option in some part of your development environment, or just stick some sort of grep command in your buildfile. It might also be possible to arrange for // HACK or any arbitrary string to be ...


0

Some of that temporary code is really just a manifestation of improper build/test/development methodology, and hopefully their existence will motivate future improvement. On git at least, you should be free to mess around with any number of feature branches until they are ready to be merged into master/trunk. Version control is supposed to help you, and ...


0

Here are are a number of solutions I occasionally use myself under various circumstances, and that you might consider helpful when applied to your own workflows: Lightweight branches that can be squashed. Git is great at this. Hack on a branch, make lots of commits, and then rebase or squash your history to edit out the noise. Use a patch queue on top of ...


0

We put everything under source control needed to build and test the current binaries and understand why things were designed/implemented/tested the way they are. That even holds for spikes http://www.extremeprogramming.org/rules/spike.html, like the ones you described; we just host them in a different sub-tree.


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.


39

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 ...


13

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 ...


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 ...


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 ...


-3

Obsolete code intertwined with "fresh" production code complicates reading and, therefore, complicates writing of new code. Such code must be kept under control and eliminated as soon as it's no longer needed. Here I wrote a short article on keeping obsolete code under control. Hope it helps.


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 ...


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 ...


0

Some environment / IDE allow for project templates. Depending on your environment this is done differently but I'd be surprised it would not be available. You can then create a project that contains this template and change it as you would any other projects. Of course once a project has been started you would have to merge the changes manually but a ...


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 ...


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 ...



Top 50 recent answers are included