Search Results

Search found 29863 results on 1195 pages for 'version'.

Page 30/1195 | < Previous Page | 26 27 28 29 30 31 32 33 34 35 36 37  | Next Page >

• Code base migration - old versioning system to modern

  - by JohnP

  Our current code base is contained in a versioning system that is old and outdated (Visual Sourcesafe 5.0, mid 1990's), and contains a mix of packages that are no longer used, ones that are being used but no longer updated, and newer code. It is also a mix of 4 languages, and includes libraries for some of our systems (Such as Dialogic, Sun Tzu {clipper}) implementations. This breaks down into the following categories: Legacy code - No longer used (Systems that have been retired or replaced, etc) Legacy code - In current use (No intentions for upgrades or minor bug fixes, only major fixes if needed) Current code - In current use, and will be used for future versions/development Support libraries - For both legacy and current code (Some of the legacy libraries are no longer available as well) We would like to migrate this to a newer versioning system as we will be adding more developers, and expanding the reach to include remote programmers. When migrating, how do you structure it? Do you just perform a dump of all the data and then import it into the new system, or do you segregate according to type before you bring it into the new system? Do you set up a separate area for libraries, or keep them with the relevant packages? Do you separate by language, system, both? A general outline and methodology is fine, it doesn't need to be broken down to individual program level.

  Read the article

• Is it good idea to require to commit only working code?

  - by Astronavigator

  Sometimes I hear people saying something like "All committed code must be working". In some articles people even write descriptions how to create svn or git hooks that compile and test code before commit. In my company we usually create one branch for a feature, and one programmer usually works in this branch. I often (1 per 100, I think and as I think with good reason) do non-compilable commits. It seems to me that requirement of "always compilable/stable" commits conflicts with the idea of frequent commits. A programmer would rather make one commit in a week than test the whole project's stability/compilability ten times a day. For only compilable code I use tags and some selected branches (trunk etc). I see these reasons to commit not fully working or not compilable code: If I develop a new feature, it is hard to make it work writing a few lines of code. If I am editing a feature, it is again sometimes hard to keep code working every time. If I am changing some function's prototype or interface, I would also make hundreds of changes, not mechanical changes, but intellectual. Sometimes one of them could cause me to carry out hundreds of commits (but if I want all commits to be stable I should commit 1 time instead of 100). In all these cases to make stable commits I would make commits containing many-many-many changes and it will be very-very-very hard to find out "What happened in this commit?". Another aspect of this problem is that compiling code gives no guarantee of proper working. So is it good idea to require every commit to be stable/compilable? Does it depends on branching model or CVS? In your company, is it forbidden to make non compilable commits? Is it (and why) a bad idea to use only selected branches (including trunk) and tags for stable versions?

  Read the article

• Where should the database and mail parameters be stored in a Symfony2 app?

  - by Songo

  In the default folder structure for a Symfony2 project the database and mail server credentials are stored in parameters.yml file inside ProjectRoot/app/config/parameters.yml with these default values: parameters: database_driver: pdo_mysql database_host: 127.0.0.1 database_port: null database_name: symfony database_user: root database_password: null mailer_transport: smtp mailer_host: 127.0.0.1 mailer_user: null mailer_password: null locale: en secret: ThisTokenIsNotSoSecretChangeIt During development we change these parameters to the development database and mail servers. This file is checked into the source code repository. The problem is when we want to deploy to the production server. We are thinking about automating the deployment process by checking out the project from git and deploy it to the production server. The thing is that our project manager has to manually update these parameters after each update. The production database and mail servers parameters are confidential and only our project manager knows them. I need a way to automate this step and suggestion on where to store the production parameters until they are applied?

  Read the article

• How to refactor when all your development is on branches?

  - by Mark

  At my company, all of our development (bug fixes and new features) is done on separate branches. When it's complete, we send it off to QA who tests it on that branch, and when they give us the green light, we merge it into our main branch. This could take anywhere between a day and a year. If we try to squeeze any refactoring in on a branch, we don't know how long it will be "out" for, so it can cause many conflicts when it's merged back in. For example, let's say I want to rename a function because the feature I'm working on is making heavy use of this function, and I found that it's name doesn't really fit its purpose (again, this is just an example). So I go around and find every usage of this function, and rename them all to its new name, and everything works perfectly, so I send it off to QA. Meanwhile, new development is happening, and my renamed function doesn't exist on any of the branches that are being forked off main. When my issue gets merged back in, they're all going to break. Is there any way of dealing with this? It's not like management will ever approve a refactor-only issue so it has to be squeezed in with other work. It can't be developed directly on main because all changes have to go through QA and no one wants to be the jerk that broke main so that he could do a little bit of non-essential refactoring.

  Read the article

• Maintaining a main project line with satellite projects

  - by NickLarsen

  Some projects I work on have a main line of features, but are customizable per customer. Up until now those customizations have been implemented as preferences, but now there are 2 problems with the system... The settings page is getting out of control with features. There are probably some improvements that could be made to the settings UI, but regardless, it is quite cumbersome setting up new instances for new customers. Customers have started asking for customizations which would be more easily maintained as separate threads instead of having tons of customizations code. Optimally I am envisioning some kind of source control in which features are either in the main project line and customizations per customer are maintained in a repo per customer set up. The customizations per project would need to remain separate but if a bug is found and fixed in a particular project, I would need to percolate the fix back to the main line and into all of the other customer repos. The problem is I have never seen this done before, and before spending time trying to find source control that can accommodate this scenario and implement it, I figure it best to ask if anyone has something less complicated or knows of a source control product which can handle this with very little hair pulling.

  Read the article

• I have a library and several small programs that use it: how should I structure my git repositories?

  - by Dan

  I have some code that uses a library that I and others frequently modify (usually only by adding functions and methods). We each keep a local fork of the library for our own use. I also have a lot of small "driver" programs (~100 lines) that use the library and are used exclusively by me. Currently, I have both the driver programs and the library in the same repository, because I frequently make changes to both that are logically connected (adding a function to the library and then calling it). I'd like to merge my fork of the library with my co-workers' forks, but I don't want the driver programs to be part of the merged library. What's the best way to organize the git repositories for a large, shared library that needs to be merged frequently and a number of small programs that have changes that are connected to changes in the library?

  Read the article

• TortoiseSVN and Subclipse icons not updating with SVN? [migrated]

  - by Thomas Mancini

  I have a repository on a network share with working directories on two separate machines. Upon making changes to my local working directory and committing them, the icons are not changing on the other developer's machine. If the Dev goes to Team Synchronize with Repository it shows the changes in the Synchronize view within Eclipse, however I was expecting the icon next to the project to change if it is not in sync with the repository. The same happens with TortoiseSVN in Windows Explorer. If we right click and check the repository for modifications it shows them, however the overlay icon on the directory is still the green check box. Am I just misinterpreting what I expect to happen, or is there a way to get these icons to change if the project is no longer in sync with the repository?

  Read the article

• Releasing software/Using Continuous Integration - What do most companies seem to use?

  - by Sagar

  I've set up our continuous integration system, and it has been working for about a year now. We have finally reached a point where we want to do releases using the same. Before our CI system, the process(es) that was used was: (Develop) -> Ready for release -> Create a branch -> (Build -> Fix bugs as QA finds them) Loop -> Final build -> Tag (Develop) -> Ready for release -> (build -> fix bugs) Loop -> Tag Our CI setup: 1 server for development (DEV) 1 server for qa/release (QA) The second one has integrated into CI perfectly. I create a branch when the software is ready for release, and the branch never changes thereafter, which means the build is reproduceable without having to change the CI job. Any future development takes place on HEAD, and even maintainence releases get a completely new branch and a completely new job, which remains on the CI system forever, and then some. The first method is harder to adapt. If the branch changes, the build is not reproduceable unless I use the tag to build [jobs on the CI server uses the branch for QA/RELEASE, and HEAD for development builds]. However, if I use the tag to build, I have to create a new CI job to build from the tag (lose changelog on server), or change the existing job (lose original job configuration). I know this sounds complicated, and if required, I will rewrite/edit to explain the situation better. However, my question: [If at all] what process does your company use to release software using continuous integration systems. Is it even done using the CI system, or manually?

  Read the article

• How to document and teach others "optimized beyond recognition" computationally intensive code?

  - by rwong

  Occasionally there is the 1% of code that is computationally intensive enough that needs the heaviest kind of low-level optimization. Examples are video processing, image processing, and all kinds of signal processing, in general. The goals are to document, and to teach the optimization techniques, so that the code does not become unmaintainable and prone to removal by newer developers. (*) (*) Notwithstanding the possibility that the particular optimization is completely useless in some unforeseeable future CPUs, such that the code will be deleted anyway. Considering that software offerings (commercial or open-source) retain their competitive advantage by having the fastest code and making use of the newest CPU architecture, software writers often need to tweak their code to make it run faster while getting the same output for a certain task, whlist tolerating a small amount of rounding errors. Typically, a software writer can keep many versions of a function as a documentation of each optimization / algorithm rewrite that takes place. How does one make these versions available for others to study their optimization techniques?

  Read the article

• Need help with ColdFusion and ASP.NET site [closed]

  - by Michael Stone

  To begin, I wasn't too sure how to title this.. I've got a few questions. First off, I've got a very big site that's in ColdFusion and we've been migrating to ASP.NET C# 4.0 the last 8 months. I've got a team of 7 programmers and no one can seem to figure out these answers, not even our senior C# programmer. We're using Team Foundation Server and we can't figure out how to only push up one small change at time. Right now we're stuck to publishing the entire site and it's causing serious issues. We've currently got the site as a Project and not a Website. We're wondering if that's one issue. I actually think it might be a problem. We're also dealing with an issue where we can't access our regular folders with relative paths. So we're first developing our admin side in .NET and We've got our regular site and then we've got another site within that for our .NET admin tools. By site, I'm referring to them actually being Sites in IIS. This also creates a problem for us when we're creating tools that upload images and want to store them and access them from our parent Site. I'd very much appreciate any advice on how to go about this in the most standardized way. So what I'm hoping for is advise on: -Publishing and managing a site/project in Team Foundation Server. Being able to push up one fix at a time if needed would be GREAT! -Any help figuring out the issuing referencing folders from my .NET child site to my parent ColdFusion site using regular relative paths. "/a/images/b/" would be nice nice instead of only being able to do "/b/images/" We're using ColdFusion 8, C# Asp.NET 4.0/Entity Framework/POCO Templates, and a Windows 2008 R2 Server. Thank you in advance for any help.

  Read the article

• How can I refactor a code base while others rapidly commit to it?

  - by Incognito

  I'm on a private project that eventually will become open source. We have a few team members, talented enough with the technologies to build apps, but not dedicated developers who can write clean/beautiful and most importantly long-term maintainable code. I've set out to refactor the code base, but it's a bit unwieldy as someone in the team out in another country I'm not in regular contact with could be updating this totally separate thing. I know one solution is to communicate rapidly or adopt better PM practices, but we're just not that big yet. I just want to clean up the code and merge nicely into what he has updated. Would a branch be a suitable plan? A best-effort-merge? Something else?

  Read the article

• Using versioning for settings in home?

  - by maaartinus

  I planned to use git for the important files in my home directory, so I can revert bad settings or transfer them to another computer as needed. But there's too much chaos there, with each program mixing wildly temporary files, caches, logs, backups, and everything. Finding anything worth saving is hard, and when I've found any settings done by myself, there were mixed with informations specific to the computer (so I could hardly take them to another one) and timestamps (so tracking useful changes is hard). Is anybody doing it or is it just hopeless? How to filter out the garbage?

  Read the article

• Handling bugs, quirks, or annoyances in vendor-supplied headers

  - by supercat

  If the header file supplied by a vendor of something with whom one's code must interact is deficient in some way, in what cases is it better to: Work around the header's deficiencies in the main code Copy the header file to the local project and fix it Fix the header file in the spot where it's stored as a vendor-supplied tool Fix the header file in the central spot, but also make a local copy and try to always have the two match Do something else As an example, the header file supplied by ST Micro for the STM320LF series contains the lines: typedef struct { __IO uint32_t MODER; __IO uint16_t OTYPER; uint16_t RESERVED0; .... __IO uint16_t BSRRL; /* BSRR register is split to 2 * 16-bit fields BSRRL */ __IO uint16_t BSRRH; /* BSRR register is split to 2 * 16-bit fields BSRRH */ .... } GPIO_TypeDef; In the hardware, and in the hardware documentation, BSRR is described as a single 32-bit register. About 98% of the time one wants to write to BSRR, one will only be interested in writing the upper half or the lower half; it is thus convenient to be able to use BSSRH and BSSRL as a means of writing half the register. On the other hand, there are occasions when it is necessary that the entire 32-bit register be written as a single atomic operation. The "optimal" way to write it (setting aside white-spacing issues) would be: typedef struct { __IO uint32_t MODER; __IO uint16_t OTYPER; uint16_t RESERVED0; .... union // Allow BSRR access as 32-bit register or two 16-bit registers { __IO uint32_t BSRR; // 32-bit BSSR register as a whole struct { __IO uint16_t BSRRL, BSRRH; };// Two 16-bit parts }; .... } GPIO_TypeDef; If the struct were defined that way, code could use BSRR when necessary to write all 32 bits, or BSRRH/BSRRL when writing 16 bits. Given that the header isn't that way, would better practice be to use the header as-is, but apply an icky typecast in the main code writing what would be idiomatically written as thePort->BSRR = 0x12345678; as *((uint32_t)&(thePort->BSSRH)) = 0x12345678;, or would be be better to use a patched header file? If the latter, where should the patched file me stored and how should it be managed?

  Read the article

• VCS strategy with TeamCity and CI

  - by Luke Puplett

  I'm planning a strategy which seeks to allow automated deployment of a website codebase into QA and production on check-in. We're using the fabulous TeamCity. We want to control release to live production; i.e. not have every check-in on Trunk go live. So my plan is to use Trunk as QA. Committing to Trunk triggers deployment to QA. I will then have a Production branch which also triggers deployment on commit, to the live site. The idea is simply that Trunk represents the mainline codebase but it hasn't gone live yet. We can branch features and do daily pulls from Trunk into those feature branches as per normal and merge/re-integrate into Trunk when we're happy for it to go to QA. When the BAs give the nod, we then smash a bottle of champagne and merge Trunk to Production and out she goes. I've never seen it done like this. Other greenfield CI strategies involve hiding features and code from production via config - this codebase can't cope with that - or just having CI on QA and taking cuts and manually pushing to live. Does my plan sound alright?

  Read the article

• need help connecting to bitbucket repository with sourceTree on windows 8

  - by pythonian29033

  I'm having trouble adding and cloning my repo on bitbucket to the sourceTree app, we're only starting with this now and we're a small company, so there's not much knowledge around this. now I've gone through The documentation on sourceTree for help, but I've noticed when I select my repo on bitbucket, it uses the repo url I select and appends a .git at the end. Then a notice message says This is not a valid source path / URL, but when I click Details... I get a dialogBox with nothing in it and an ok button. and when I'm done entering the details the 'Clone' button remains disabled. Is this Windows 8 or am I actually doing something wrong? Now I usually use ubuntu, but we just got these new ASUS ultrabooks at work and it's a pain to install any linux Distro on here. So I'm stuck with windows 8

  Read the article

• Develop in trunk and then branch off, or in release branch and then merge back?

  - by Torben Gundtofte-Bruun

  Say that we've decided on following a "release-based" branching strategy, so we'll have a branch for each release, and we can add maintenance updates as sub-branches from those. Does it matter whether we: develop and stabilize a new release in the trunk and then "save" that state in a new release branch; or first create that release branch and only merge into the trunk when the branch is stable? I find the former to be easier to deal with (less merging necessary), especially when we don't develop on multiple upcoming releases at the same time. Under normal circumstances we would all be working on the trunk, and only work on released branches if there are bugs to fix. What is the trunk actually used for in the latter approach? It seems to be almost obsolete, because I could create a future release branch based on the most recent released branch rather than from the trunk. Details based on comment below: Our product consists of a base platform and a number of modules on top; each is developed and even distributed separately from each other. Most team members work on several of these areas, so there's partial overlap between people. We generally work only on 1 future release and not at all on existing releases. One or two might work on a bugfix for an existing release for short periods of time. Our work isn't compiled and it's a mix of Unix shell scripts, XML configuration files, SQL packages, and more -- so there's no way to have push-button builds that can be tested. That's done manually, which is a bit laborious. A release cycle is typically half a year or more for the base platform; often 1 month for the modules.

  Read the article

• What's the best way to explain branching (of source code) to a client?

  - by Jon Hopkins

  The situation is that a client requested a number of changes about 9 months ago which they then put on hold with them half done. They've now requested more changes without having made up their mind to proceed with the first set of changes. The two sets of changes will require alterations to the same code modules. I've been tasked with explaining why them not making a decision about the first set of changes (either finish them or bin them) may incur additional costs (essentially because the changes would need to be made to a branch then if they proceed with the first set of changes we'd have to merge them to the trunk - which will be messy - and retest them). The question I have is this: How best to explain branching of code to a non-technical client?

  Read the article

• Advanced subversion techniques, what am I missing?

  - by Derek Adair

  I started using SVN about 9 months ago and it's been a game changer to say the least. Although, I feel I'm still a bit lost. I feel like there is a lot more I need to take advantage of to really step up my application development. For example I would like to be able to quarantine any volatile/major changes into some kind of 'sub-repository' or something. I'm finding that major changes are impeding minor bug fixes that are quite urgent. How can I push one simple update without pushing incomplete or broken code?

  Read the article

• How do I check that my tests were not removed by other developers?

  - by parxier

  I've just came across an interesting collaborative coding issue at work. I've written some unit/functional/integration tests and implemented new functionality into application that's got ~20 developers working on it. All tests passed and I checked in the code. Next day I updated my project and noticed (by chance) that some of my test methods were deleted by other developers (merging problems on their end). New application code was not touched. How can I detect such problem automatically? I mean, I write tests to automatically check that my code still works (or was not deleted), how do I do the same for tests? We're using Java, JUnit, Selenium, SVN and Hudson CI if it matters.

  Read the article

• TFS SQL Deployment Data Script

  - by Greg

  We are using TFS and SQL 2005 (looking to upgrade to SQL 2012 if that makes a difference). We store our database schema in a Visual Studio Database project (VS 2010). When code is released to live we currently use the Visual Studio Database Project to build a script for all our schema changes. The problem we have been getting is having to alter or add to that script to add/fix data for the deployment. For example if we add a new non-nullable column to an existing table we need to populate that column with data during the insert. Other times we may want to create new records in transactional tables (e.g. assign specific users to a new security access). Do Visual Studio Database Projects have a way to store these scripts that only need to be run once and somehow include them in the build? Does it know which scripts need to be run (for example if we are inserting default data we don't want to do that again a second time)? OR Is there a better way to manage these scripts?

  Read the article

• What source control to use for my private gaming server?h

  - by crosenblum

  It has sql server components, client launcher, server software. I want to use an online resource where people can make updates, and make it easier to roll out any changes to players. Most of the files are just text files, or gtx image files. I don't think this qualifies as open source, so I don't know what to do. I tried github, and have a free account there, but it was really clunky, mass adding every file to be comitted. I really dont' like subversion but if that's the best option, i'll use it. The other people who will need access to the files will have no familiarity with any kind of source control, so I need an easy system for them to download files, make changes, and comit to the repository. Any suggestions?

  Read the article

• How to keep the trunk stable when tests take a long time?

  - by Oak

  We have three sets of test suites: A "small" suite, taking only a couple of hours to run A "medium" suite that takes multiple hours, usually ran every night (nightly) A "large" suite that takes a week+ to run We also have a bunch of shorter test suites, but I'm not focusing on them here. The current methodology is to run the small suite before each commit to the trunk. Then, the medium suite runs every night, and if in the morning it turned out it failed, we try to isolate which of yesterday's commits was to blame, rollback that commit and retry the tests. A similar process, only at a weekly instead of nightly frequency, is done for the large suite. Unfortunately, the medium suite does fail pretty frequently. That means that the trunk is often unstable, which is extremely annoying when you want to make modifications and test them. It's annoying because when I check out from the trunk, I cannot know for certain it's stable, and if a test fails I cannot know for certain if it's my fault or not. My question is, is there some known methodology for handling these kinds of situations in a way which will leave the trunk always in top shape? e.g. "commit into a special precommit branch which will then periodically update the trunk every time the nightly passes". And does it matter if it's a centralized source control system like SVN or a distributed one like git? By the way I am a junior developer with a limited ability to change things, I'm just trying to understand if there's a way to handle this pain I am experiencing.

  Read the article

• Structure of a Git repository

  - by Luke Puplett

  Sorry if this is a duplicate, I looked. We're moving to Git. In Subversion, I'm used to having \trunk, \branches and \tags folders. With Git, switching between branches will replace the contents of the working directory, so am I right to assume that the way we used to work just doesn't apply with Git? My guess is that I'd have a repo folder with maybe a gitignore and readme.txt, then the folders for the projects that make up the repo, and that's it.

  Read the article

• Why not commit unresolved changes?

  - by Explosion Pills

  In a traditional VCS, I can understand why you would not commit unresolved files because you could break the build. However, I don't understand why you shouldn't commit unresolved files in a DVCS (some of them will actually prevent you from committing the files). Instead, I think that your repository should be locked from pushing and pulling, but not committing. Being able to commit during the merging process has several advantages (as I see it): The actual merge changes are in history. If the merge was very large, you could make periodic commits. If you made a mistake, it would be much easier to roll back (without having to redo the entire merge). The files could remain flagged as unresolved until they were marked as resolved. This would prevent pushing/pulling. You could also potentially have a set of changesets act as the merge instead of just a single one. This would allow you to still use tools such as git rerere. So why is committing with unresolved files frowned upon/prevented? Is there any reason other than tradition?

  Read the article

• What Part of Your Project Should be in Source Code Control?

  - by muffinista

  A fellow developer has started work on a new Drupal project, and the sysadmin has suggested that they should only put the sites/default subdirectory in source control, because it "will make updates easily scriptable." Setting aside that somewhat dubious claim, it raises another question -- what files should be under source control? And is there a situation where some large chunk of files should be excluded? My opinion is that the entire tree for the project should be under control, and this would be true for a Drupal project, rails, or anything else. This seems like a no-brainer -- you clearly need versioning for your framework as much as you do for any custom code you write. That said, I would love to get other opinions on this. Are there any arguments for not having everything under control? Is this sysadmin a BOFH?

  Read the article

< Previous Page | 26 27 28 29 30 31 32 33 34 35 36 37  | Next Page >