Maybe below sounds a little bit stupid so sorry in advance.
I use Visual Studio 2019 and Git as version control. I am not using the integrated Git that comes with Visual Studio, instead I am using the standalone version of GitExtensions.
Honestly I am newbie wit Git. I had always used TFVC.
Now I have a diff file (file.diff) which has some changes and I need to apply it. I have some branches and I need to apply it in a concrete one.
I have googled but I have not found a detailed explanation on how to do it. In GitExtensions web site, the explanation is minimal and I honestly don't quite understand the patch process at all.
So I would need that someone guide me and be so kind to help me with a detailed step by step explanation (some screenshots would be highly appreciated) or tell me somewhere where this process is described in detail: web, free book, etc.
Sorry, I need to apply the patch to a production environment so this is my first time and I do not want to break nothing.
Related
I am new to GitHub, ADO and VSC. I keep looking for how to resolve a merge conflict and seeing articles that mention how to do this but for earlier versions of VSC. I am using 2022 and I do not understand what it means in the docs explanations that say to use an extension to do this. All I need is a little help in plain english about what to do. Such as, this is the extension you need, this is how to install it and this is how to use it. None of the docs content is this straightforward and I understand it is to cover a wide audience. But I get lost in all the extraneous information and history. I have no resources to help me and am getting so frustrated with the plethora of information that tells me nothing practical. Please help.
When using dashboard (https://melpa.org/#/dashboard) in emacs, how can I set it up so that it ignores directories or filenames matching a pattern like .gitignore ?
For example by default it shows ~/.emacs.d/elpa/*
The emacs community is friendly... but probably not as helpful as they could be. You could try filing a GitHub issue with the dashboard developer (here: https://github.com/rakanalh/emacs-dashboard/issues). If you ever did figure out a fix for your own issue, I bet the dashboard maintainer would be glad to hear about it.
Avoid plugins. Help on opensource plugins is minimal if you are not comfortable with developer jargon, politics and technical skills to understand the source code.
Just wait and see for yourselves - the emacs tag has 5.4K watchers, on average you get about <20 views per question, when do you think the question will be answered ?
Semantics aside, the suggestion is to just use the built in bookmarks feature.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Bookmarks.html#Bookmarks
I was working around with Postgres a bit. I am trying to get familiar to editing the source code of the same.
One of the suggested exercise was to change the buffer replacement policy of the system of Postgres 7.4. (It was in one of the homeworks of some university. First few links of google. I am just using them to get familiar to the code.)
I understand parts of it but I am not able to fully understand how to modify the system. I mean, I know the particular files,buffer folder files in the src/backend/storage location as the files where I have to make changes, but how to implement my own scheme and test it, is going over my head.
So my question is, can anyone help me with some basic code snippet understanding? (Probably, give me idea how to solve the question mentioned above? and how to test it ( most important). ) (This is not a homework of any sort, promise. I am just trying to get a hang of things.)
If not, can anyone refer me to some book which can help me with modification of the postgresql source code? There are books to use postgresql, but I couldn't find any that could help to modify the source code.
P.S: I know the online documentation of PGSQL source code resides at: http://doxygen.postgresql.org/
But I am not able to understand a lot from there. I need a book that can help the layman!
Any help is much appreciated!
Apart from the Developer FAQ your best starting point will be the PostgreSQL mailing lists.
You might start with posting to http://archives.postgresql.org/pgsql-novice/ ("No question is too simple for this list")
And if you really start changing the source code you will need to subscribe to http://archives.postgresql.org/pgsql-hackers/ as well.
And don't use the 7.x source code. PostgreSQL is at Version 9.1 now and I'm sure studying the ancient history won't be very helpful.
I'm currently working on a project that's been going on for several years straight. The development-team is small (less than 5 programmers), and source-control is virtually non-existent, and the deployment-process as is is just based on manually moving files from one server to another. The project is in classic ASP, so building isn't an issue, as both deployment and testing is just about getting the files to where they need to be and directing the browser at the correct location. Currently all development is done on a network-drive which is also the test-server. The test-server is only available when inside the the local network (can be accessed trough vpn), and is available on the address 'site.test' in the browser (requires editing to the hosts-file on all the clients, but since there are so few of us that hasn't proven to be any problem at all). All development is done in visual studio. Whenever a file is change the developer that changed the file is required to write the file he changed into a word-document and include a small description as of what was changed and why. Then, whenever there's supposed to be a version-bump (deployment), our lead-developer goes trough the word-document and copies every file (file by file) that has changed over to the production-server. Now, I don't think I need to tell you that this method is very error prone (a developer might for instance forget to add that he changed some dependency, and that might cause problems when deployed), and there's a lot of work involved with deploying.
And here comes the main question. I've been asked by the lead developer to use some time and see if I can come up with a simple solution that can simplify and automate the "version-control" and the deployment. Now, the important thing is that it's as easy as posible to use for the developers. Two of the existing developers have worked with computers for a long time, and are pretty stuck up in their routines, so for instance changing it into something like git bash wouldn't work at all. Don't get me wrong, I love git, but the first time one of them got a merge-conflict they wouldn't know what to do at all. Also, it would be ideal to change to a more distributed development-process where the developers wouldn't need to be logged into vpn (or need internet at all) to develop, and the changes they made offline could be synced up when they were done with them. Now, I've looked at Teem Development Server from Microsoft because of it's strong integration with Visual Studio. As far as I've tested it seems possible to make Visual Studio prompt the user if they want to check in changes whenever the user closes Visual Studio. Now, using TFS for source-control would probably eliminate most of the problems with the development, but how about deployment? Not to mention versioning? As far as I've understood (I've only looked briefly at TFS), TFS has a running number for every check-in, but is it possible to tell TFS that this check-in should be version 2.0.1 of the system (for example), and then have it deploy it to the web-server? And another problem, the whole solution consists of about 10 directories with hundreds of files in, though the system itself (without images and such) is only 5 directories, and only these 5 should be deployed to the server, is this possible to automate?
I know there's a lot of questions here, but what is most important is that I want to automate the development process (not the coding, but the managing of the code), and the deployment process, and I want to make it as simple as possible to use. I don't care if the setup is a bit of work, cause I got enough time at hand to setup whatever system that fits our needs, but the other devs should not have to do a lot of setup. If all of the machines that should use the system needs to be setup once, that's no problem at all, cause I can do that, but there shouldn't bee any need to do config and setups as we go.
Now, do any of you have any suggestions to what systems to use/how to use them, in order to simplify the described processes above? I've worked with several types of scm-systems before (GIT, HG and SubVersion), but I don't have any experience with build-systems at all (if that is needed). Articles, and discussion on how to efficiently setup systems like this would be greatly appreciated. In advance, thanks.
This is pretty subjective territory, but I think you need to get some easy wins first. The developers who are "stuck up in there ways" are the main roadblock here. They are going to see change as disruptive and not worth it. You need to slowly and carefully go for the easy wins.
First, TFS is probably not going to be a good choice. It's expensive, heavy, and the source control in TFS is pretty lousy. Go for Subversion: it's easy to setup and easy to use, and it's free. Get that in place first, and get the devs using it. Much easier said than done.
Later (possibly much later), once the devs are using it and couldn't imagine life without a VCS, then you could switch to Hg or Git if you need first class branching and all those other nice features.
Once you have Subversion in place, you can use something like JetBrains TeamCity or Jenkins, both of which are free and easy to use. However, I'm just assuming you don't have a lot of tests and build scripts that the CI server is really going to be running, so it's far more important that you get VCS first. In all things: keep it as simple as possible. Baby steps. Get some wins, build trust, repeat.
I can't even begin to think where to begin with this! Intending no offense directed at you, apart from the mention of git and HG, this post could have been written 10 years ago.
1) Source control - How can a team of developers possibly work effectively without some form of source control? Hell, even if it's Visual Source Safe (* shudder *) at least it would be something. You have to insist that the team implement source control. You know what's available so I won't get into preaching about that. (However, Subversion with TortoiseSVN has worked quite well for me.)
2)
"write the file he changed into a
word-document and include a small
description as of what was changed and
why"
You have got to be kidding... What happens if two developers change the same file? Does the lead then have to manually merge two changes that s/he extracts from the word doc? Please see #1 and explain to them how commit comments work.
Since your don't really need to "build" (i.e. compiled, etc.) anything, you should be able to solve most of your problems with some simple tools. First and foremost you need to use a source control solution. Yes, the developers would have to learn how to use another tool (EEEK!). You could do the initial leg work of getting the code into the repository. If you have file access to the other developers machines, you could even copy a checked-out working copy to their machines so they wouldn't have to do the checkout themselves (not really that hard). You could then use all the creamy goodness of version control to create version branches when each deployment needs to be done. You could write simple scripts using the command line SVN tools to check out said branches and automatically copy the files to the target server(s). Using a tool like BeyondCompare, the copy process could be restricted to only the files that are different (plus BC can handle an FTP target if that is an issue). By enforcing commit comments on the SVN repo, you'll guarantee that the developers provide comments, and for each set of changes between releases you could very easily generate a list of all those comments using the CSM log retrieval features.
I'm assuming Mercurial is for having an updated website and it archiving the old stuff? Easy to test things and such?
My question is, how exactly should I get started and can somebody give me a crash course in using Mercurial and using the following techs below:
Notepad++ for coding
FTP
PHP/MySQL
Jquery & other js libraries
I use windows and would like to keep things fairly simple. I'm developing 1 website currently and want some kind of CVS system in place. Or should I just stick to my current edit file in notepad++ and upload via ftp method and make a backup copy of everything every once and a while?
Any thoughts?
EDIT: I'm doing http://bugtracker.gttools.com/public/wiki/bluehost/Mercurial right now in order to try and 'install' it.
I'd definitely recommend taking a read through the excellent HGinit http://hginit.com/ site in addition to the official guide.
Definitely try and move across to using some form of version control (SVN, git or mercurial) as it'll save you down the line.
Mercurial is a distributed version control system, much like Git but allegedly slightly simpler.
A good tutorial by Joel Spolsky can be found here.
If you read up on https://www.mercurial-scm.org/guide under Basic Workflow you should be able to figure out how to work with it while editing files using Notepad++ etc.
From your question it sounds like you don't know much about version control (like you have a very basic grasp of what it is and why it is useful). So perhaps the first thing you should do is read up on that in general first of all.
But in terms of using Mercurial I don't think you will find a better insight into how to use it and why it is so good than Joel's tutorial, which you can find here hginit Tutorial
HGInit is a good tutorial for mercurial. Basically you have to hg init in the directory you want to be under version control. If you don't like the command line, you can also use gui tools, like tortoisehg.
If I'm not mistaken you also want to upload the latest version to the website. If I'm right ftp access won't be enough for this (unless you define a post-commit hook, that uploads the directory using ftp).
I'm assuming Mercurial is for having
an updated website and it archiving
the old stuff? Easy to test things and
such?
Not sure what you mean here. Mercurial (and all version control systems) lets you archive your changes as you make them, label and manage your releases so you can track code that goes together, and branch when you need to do parallel development.
You should be checking in your changes as you make them. If anything goes wrong during development, you can roll back to the last good version you had. It's a great way to make sure that you don't lose days and days of work because you forgot to check in.
Check in early, check in often.