We are a team of 3.
We have 3 local versions of a project on Visual studio. We have not pushed those versions to gitlab yet.
How do we merge those 3 versions into one?
What we have tried so far is upload first project in gitlab. Then we clone back locally. We deleted it. On its place we have copied the second version of the project. We wanted to pull the first version in order to merge them but it says - project is up to date.
We don't want to do that by hand because it will take a long time, we would rather do it automatically. How do we do that?
Thanks in advance
Related
Because we've done some rearranging of our documentation setup, I have two separate read the docs projects which I need to build from the same GitHub repo. One of them is brand new, and the other used to be pointed to the old repo.
I have set up a webhook on each project, and added both these webhooks to the repo.
The problem is that in the project that used to be pointed to the old repo, the stable build is still associated with the SHA of the latest release on the old repo, which does not exist in the new repo. This causes the stable build to fail.
One other thing I hope to solve, when activating some of the new versions (which used to exist in the old repo) an "_a" is added to then of the published version name, even though there are not multiple publishable versions with the same name.
I'm wondering: is it possible to completely refresh all of the RTD-detected versions and tags? I think doing so would solve both these issues.
I've tried "wiping" the builds but that doesn't help, I have read the RTD docs on versions many times, and I've triggered new push events from github (which are sent and received successfully) but still can't make any progress.
The best way to solve this turned out to be just recreating the RTD projects. If anyone else comes across this issue, you could check out the ticket I made on the RTD repo https://github.com/rtfd/readthedocs.org/issues/3763.
Trigger a Build on any of the existing versions that RTD knows about. After that build job starts the Versions list will be updated from the git repo.
I'm trying to commit an out of date version of a java project, but it won't let me without updating it. I do not want to update it because the updated version is all messed up, so I checked out an older version... Is there some way of creating a new project on the svn with it? I can't get it to show up on our repository. What option do I select when I right click the project and then select Team?
Branch your working copy to the main repository, so you will have two working copies to refer. you will have access to both the versions so you can do the needful...link for reference
see Branches, Tags and Trunk....
Is Clone the only way for me to get my own repository to a different machine?
I have published my repository from my home PC and am trying to edit it from another.
I'm using Github for Windows but cannot see how to get the published repository to a second machine in order to edit the code and republish the changes so I can later use on the original PC.
The general approach for Distributed Version Control Systems is to:
Clone the repository (from the server)
Update your code (local, in your working directory)
Commit the code (local, in your working directory)
Push the commits (to the server)
Pull the new commits (from the server) to another development PC.
Typical development cycles iterate between steps 2 and 3. And sometimes 4 (to store your changes off-site) and 5 (to grab changed made by others).
As I suppose that 'Github for Windows' uses git(hub), it is also a DVCS and works also with these steps.
The proper way to do this is to clone the repository onto your second machine, straight from the source (Github). Sharing one clone between multiple machines is not recommended except in a few circumstances.
Resolved.
I had to delete the local repository. Github then prompted me with an error and the option to "Clone again", this clone again worked.
Thanks.
We have the standard basic TFS 2010 branches setup - Dev <-> Main <-> Release.
We've merged up and down the chain multiple times over the past several months with no issues.
A couple of weeks ago we merged Main -> Release and deployed a new version of software.
As far as we know there were no issues with the merge and the new version in Release seems fine.
Today we were preparing to merge another set of changes from Main to Release and when we brought up the window to see what changesets were available to merge - surprisingly TFS listed ALL changes from the beginning of the application!
Is there some common/stupid thing we could have done so that TFS thinks the Release branch is no longer current or needs to have ALL changesets re-merged from Main to Release?
The issue is not specific to any developer's machine.
What's also strange is I can do View History on the Release branch, and I see all the changesets just fine - so I know Release is good.
The only thing out of the ordinary in the changes going from Main to Release are changes to the solution and project files where we upgraded to Visual Studio 2012 and changed the target framework to 4.5. When we went from Dev to Main with these changes however, it didn't cause any kind of problem like this. It just updated the modified sln, proj, etc files.
Has anyone ever ran across something like this?
it appears this was caused by a "resurrected" file that had previously been deleted (and another file created using the same name).
reference
I've just started using subversion, and have read the official documentation (svn book), cheat sheet and a couple of guides. I know how to install subversion (in linux), create a repository (svnadmin create), and import my Eclipse project into the repository (SVN import), view the repository files (using svn list).
But I am unable to understand some of the other terminologies. For example, after importing my Eclipse project into the newly created repository I have made changes to my Eclipse project (more than 1 file). Now, how should I update the repository with this added files/changes made to my Eclipse project?
The svn update command brings the changes from the repository into your working copy - which is the opposite of what I want i.e. bring the changes I made in my Eclipse project into the previously imported project in repository. If I am correct, you update the repository more often (as you keep extending your project implementation) than your current project (with update).
Also, I do not understand when would you use svn merge. The svn book states it applies the differences between 2 sources to a working copy. Is there a scenario which would explain this?
Finally, can I have more than 1 project checked into the repository? Or is it better to create a new repository for each project?
The term you are looking for is "commit".
Subversion does not exclusively lock a file for editing (though there is a command to do this if you really, really want to). So it is possible that you will need to merge two different users' sets of edits on a file, or even edits from two different working copies in two different locations on your machine.
Multiple projects is fine. Best approach IMHO is repository/project/trunk etc rather than repository/trunk/project.
Three things about SVN you should know:
Trunk - The main version of your code
Tags - 'Tagged' Versions of your code (i.e. v1.2.5-release)
Branches - Forks of the code for divergent development paths. We typically fork new branches to work on different versions, so if the current version is 1.2.4, you'd branch for 1.3's development. So if emergency changes to 1.2 need to be made (i.e. 1.2.5) you can work on it without worrying about what you broke by refactoring / feature adding in your 1.3 branch. The merge operation is designed so you can merge 1.3's branch back into trunk when you're ready to release 1.3, or a similar operation. You can also merge individual files (if two or more developers edited the same file at the same time and now you need to 'merge' the changes into the same file.
Each project in your repository should have 3 folders in it:
/trunk
/branches
/tags
These house the three points above. You don't have to have these folders, but you should. Other more mature VCS like Mericual/Git have the concepts of tags and branches baked into the system. In SVN these are more of a convention/reccomendation.
Terminology
Working Copy - The copy on your hard-drive, that contains all your edits, etc...
Add - Registers a file for tracking in version control
Update - Updates the working copy with changes from the server repository
Commit - Updates the server repository with changes from the working copy
Switch - Replaces the working copy with another folder within the server repository
Diff - Does a differential analysis of two files / versions of a file to see the changes between them.
Merge - Attempts to apply the changes from one or more files into another, highlighting conflicts.
Patch - A set of differences that can be used to update a file.
You commit changes to the repository
Merge is useful when you need to maintain two branches of a repository. For examples v1.x with most recent security fixes and the alpha version 2. That allows you to make the fixes in the 1.x code, whith the resulting binary for existing customers, and you can merge the changes into version 2 so fixing the bugs that weren't already caught.
I suggest you look around for 'typical svn workflows'. They will give you the big picture of the 'most common tasks'.
What you want to do is 'commit' the changes made to your files to the repository.
You need to merge in case of a conflict (when 2 or more people are working on a project and commit to the same repo. conflicts might arise).
Check the available articles on SVN kai remember to read about the sample/typical workflows or working scenarios with SVN.
Fully agree with David, but as far as question 3 is concerned, personally, I would distinguish between use cases:
Production: One project per repository. And do get warm with the mentioned tag/trunk/branch concept, it really helps a lot
Testing: I have one single repository where I have put virtually all my experimental codes (approx. 10 languages with x codes per language). Reason is: One experimental code takes me 1-2 minutes, creating a repository on a remote host, using ssh-security sometimes takes longer ;-)
Cheers
EL