WinMerge: I used it in the past, it's fairly nice but the interface is not "immediate" - which means you have to use the toolbar instead of arrows to the side of the code. The other question that may arise is: why CodeCompare for Merging actions? Take a look at the competition: This will be further addressed in a future article. On a more general note, some Game Development teams resolve the conflicting general need to both have distributed versioning of code and file locking for binary files by making a Frankenstein - using both in a complicated setup. As of writing this (Unity 5.1 is active) this has not been resolved to the satisfactory level. This makes a CVCS pretty much useless, and yes: there are scripts out there that help with the problem (locked file becomes grayed out in the hierarchy) but those are not real solutions - nothing about those is low-level industry-strength guarantee that taking of the locked file won't happen. Unfortunately Unity does not honor the flag: it allows editing of the file either way. They work by setting a specific file flag (on a file system level) that is 'Read-only' to denote the lock status. I would have chosen CVCS if it was not for one thing: they don't really work with Unity. As a generalization, DVCSs are better for code collaboration and CVCSs are better for binary and asset collaboration. DVCSs presume the work will be merged as text files (code) and don't even have the option to lock the file - it's not in their nature. These are, in theory, much better for Artists, because they can lock individual files for editing, thus preventing other team members to "step on each other's toes" by editing the same files and doing redundant work. On the other hand there are Centralized VCSs like Perforce or SVN. Imagine you have a job to complete and 2 engineers to do it: one engineer that can complete a job within 30 hours, but he knows much more and is more popular (his name starts with G) and you have another engineer which can complete the same job within 5 hrs without much fuss (and his name starts with M). I also really liked how Mercurial did things in general, so Git vs Mercurial choice was very clear for me. I can echo the general attitude that you can learn Hg syntax within a day or two, while with Git I was constantly surprised as soon as I had to 'wander off the beaten path'. Having learned a bit of Git's peculiar syntax, I was curious to see how Mercurial (Hg) compares to it. Git has its drawbacks and complications, and having worked with EGit (extension for Eclipse that provides Git functionality) I found it to be very problematic. This helps us alter the commit history and remove the history we deleted earlier.First, a little intro about VCS': why Mercurial for Game Development? In the past I have worked with another Distributed VCS you might have heard about - Git. Now, we'll modify this by deleting the text “ pick 535f7ea blob file removed “. message (or the oneline, if no original merge commit was create a merge commit using the original merge commit's # l, label = label current HEAD with a name # b, break = stop here (continue rebase later with 'git rebase -continue') # x, exec = run command (the rest of the line) using shell # f, fixup = like "squash", but discard this commit's log message # s, squash = use commit, but meld into previous commit # e, edit = use commit, but stop for amending # r, reword = use commit, but edit the commit message This opens our nano editor showing: pick 535f7ea blob file removed With this command, we enter into an interactive rebase: $ git rebase -i 5bac30b So we'll use the SHA1 key from the history of the entry preceding the one we want to remove. Our aim is to remove the blob file from our commit history. * 535f7ea (HEAD -> master) blob file removed We need the SHA1 key from the git log to use this approach: $ git log -graph -full-history -all -pretty=format:"%h%x09%d%x20%s"
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |