Jump to content

  • Log In with Google      Sign In   
  • Create Account


Version control for begginers


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
49 replies to this topic

#41 Cornstalks   Crossbones+   -  Reputation: 6878

Like
1Likes
Like

Posted 25 January 2013 - 01:04 AM

I've installed multiple different source control tools before (and apparently still have TortoiseSVN and TortoiseCVS installed), but they puked over my projects' neatly organized folders with special files and junk

SVN used to be really bad with this, creating a .svn folder in every directory. However, that's been changed for a while now (since 1.7, I believe) and now it only creates one .svn file at the top level of your repository and sticks all of its junk in there. Git only has one .git folder at the top level as well. No idea about Mercurial (thanks for writing the name so I can copy 'n' paste it!), I've never tried it. I know in Git you can also make a .gitignore file if you want and put files or extensions you want Git to ignore. I believe SVN stores that in its .svn folder so you only get the one item.
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

Sponsor:

#42 EWClay   Members   -  Reputation: 655

Like
1Likes
Like

Posted 25 January 2013 - 03:51 AM

I would say manually modifying the repository under any source control system is extremely risky. Why would you want to do that anyway?

I can confirm that Perforce does not add any special files to your project folder. SVN does, as I recall. Can't speak for the others.

#43 SeraphLance   Members   -  Reputation: 725

Like
2Likes
Like

Posted 25 January 2013 - 07:44 AM

All three add a top level .<name> folder to your stuff; .git, .hg, and .svn respectively.

 

Both Mercurial and git have a .<name>ignore file that lets you select files to ignore on pushing.  The syntax is the same to my knowledge.

 

Really, the only significant difference between git and mercurial that seems to come up when I use them is that mercurial more closely follows subversion's command names, whereas git seems to make it a point not to.

 

Regarding which to use, it really doesn't matter.  Subversion is probably the easiest to use, but the others aren't that hard.  Mercurial took me a while to set up with BitBucket and TortoiseHG/VisualHG, but "a while" in this context is a matter of a couple hours learning how the environment works.  That's more than tolerable.



#44 samoth   Crossbones+   -  Reputation: 4065

Like
2Likes
Like

Posted 25 January 2013 - 08:54 AM

If I wanted to manually modify the up-to-date repository without invoking any version control tool or command, which ones permit me to do so?


In Subversion this is probably possible, though not easy and not advisable. You would have to edit Sqlite (presumably using a Sqlite editor), and DELTA files in a hex editor or a specially written tool. Older revisions used Berkeley DB once upon a time, so it was never easy. Hand editing is not something that was intended in the design, ever.

Git explicitly tries to prevent editing by only referencing everything (files, folders, revisions) by their SHA-1 value. Presumably this is "secure" as long as you don't have a preimage attack on SHA-1 that runs in minutes/seconds. It is necessary in the case of a distributed system, too, because otherwise you have hardly any way of telling what's authentic and what was changed and tampered with.

(Note that pre-imaging SHA-1 is not alltogether unlikely to happen. The best known attack so far has 2^61 complexity, that's about 7200 CPU-years on an average dektop computer. Now taking multi-core and so into account, if you can get a cluster of a thousand or so machines together, it's almost feasible...)

Edited by samoth, 25 January 2013 - 09:10 AM.


#45 Pash   Members   -  Reputation: 233

Like
0Likes
Like

Posted 25 January 2013 - 09:09 AM

I use TortoiseGit and GitHub for my upstream repo. Its easy enough to setup and there are guides on youtube etc on how to do it. I would suggest you always keep another manual backup as well because of the nature of the git workflow systems. I usually write some powershell scripts or bash scripts to do file copies to my storage device daily. Probably seems overkill, but having a practical backup solution is a good idea.


Please Add Rep if I helped // Working on untitled 2D platformer (more to come soon)
Twitter - @MarkPashby

#46 Yrjö P.   Crossbones+   -  Reputation: 1410

Like
1Likes
Like

Posted 25 January 2013 - 09:57 AM

SVN is not bad, and it obviously compares favorably to Git on learnability, but I don't see why you'd recommend it over Hg to someone who is new to VCSs. For someone starting from zero, both SVN and Hg are easy to learn, but SVN doesn't seem to have any real upside. I know SVN can do partial checkouts, but being able to do those wasn't very useful for me even when working on a 5+MLOC codebase, much less with smaller codebases. And the larger the project, the more rage-inducing it is to lack modern (distributed) version control functionality.

#47 3Ddreamer   Crossbones+   -  Reputation: 2557

Like
0Likes
Like

Posted 25 January 2013 - 12:55 PM

And the larger the project, the more rage-inducing it is to lack modern (distributed) version control functionality.

 

"...more rage-inducing..."  LOL.... As if everything else - modern functionality - is Iess rage-inducing, but rage-inducing never the less.  LOL


Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

 

by Clinton, 3Ddreamer


#48 Ravyne   Crossbones+   -  Reputation: 5665

Like
1Likes
Like

Posted 25 January 2013 - 02:10 PM

Git explicitly tries to prevent editing by only referencing everything (files, folders, revisions) by their SHA-1 value. Presumably this is "secure" as long as you don't have a preimage attack on SHA-1 that runs in minutes/seconds. It is necessary in the case of a distributed system, too, because otherwise you have hardly any way of telling what's authentic and what was changed and tampered with.

 

QFE.

 

AFAIK this is actually one of the substantial philosophical differences between git and mercurial (hg) -- git is architected with security truly in mind, rather than something which is sort of an assumed by-product of revision control. Linus wanted to be sure that if the linux kernel source code was contaminated or just plain borked, accidentally or intentionally, that the warning flares would go up instantly. If you're in an environment where you cannot trust contributions (or where the consequences of being wrong are serious) then this additional attention to security might be important to you. I forget which of the *BSD's kernel repository was recently attacked, but it was, and a lot of work was lost, deadlines were missed, and much woe was had. There's always a possibility that disagreements between devs can escalate into malicious actions.

 

This also speaks to the distributed model in general somewhat -- with a centralized system you have to maintain the security of the repository and make sure its backed up because that's the one place that maintains the entire history. When you pull down a local copy of this source tree you only get the info that's relevant to that time. In a distributed system, *everyone* has the entire history, and even if the "central/official" repo was destroyed, it's solved by simply pushing it out from one of the devs' local copies. Linus has said that he doesn't even bother to back up the linux kernel source anymore, because he can just assume that its been replicated hundreds or thousands of times by devs all over the world -- way better than any RAID or backup strategy. Of course, you have to have many active developers before this is true, its just nice that the robustness of the system is directly related to how much its relied upon.


Edited by Ravyne, 26 January 2013 - 04:24 PM.


#49 larspensjo   Members   -  Reputation: 1525

Like
1Likes
Like

Posted 25 January 2013 - 03:49 PM

There are some things not mentioned above, which had a big influence on my workflow.

  1. The git two step use of the list of staged files (in the index). I don't know what other version managers that use this. Anyway, at first I found it awkward to use, just adding work and effort. But then I learned to use it efficiently. When developing a new functionality, I continuously move changes back and forth between staged and not staged. Especially, I move hunks and lines, not complete files. Typically is that you have some changes that should go into the commit, and some temporary changes that are used for testing. So the temporary changes are not staged. There are also several changes that I "randomly" add to the source code during the investigation of how to best design the change I want. This way, it is easy to revert the temporary changes, while still keeping the staged changes. I use "git gui" for this, as not all git UI tools support it.
  2. There is a conflict in version management. On the one hand, you should check in as frequently as possible. But on the other hand, you should not check in things that break functionality for others in the development team. If you check in frequently, it is usually easier to merge from the origin. This is helped by distributed version management. You can check in as frequently as you want, but should wait with the push until you are confident you don't break things you are not supposed to break. It is a tendency of programmers to hesitate to check in until they feel confident with their change, which can lead to several weeks until there is a check-in.
  3. Git is very advanced. What is a little tricky, is that it is possible to rebuild the tree. This can easily lead to problems if you don't know what you are doing. It should not be a problem in a single user environment.
  4. Github uses git. Sure, there are other alternatives, but Github is one of the better?
  5. If you have big projects, you need to organize the version management into sub projects. You want to define a "product" that consists of defined versions of libraries. That is more or less supported by the version control systems. Maybe the strongest one here is ClearCase? But I wouldn't recommend ClearCase.

Current project: Ephenation.
Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

#50 SiCrane   Moderators   -  Reputation: 9106

Like
0Likes
Like

Posted 25 January 2013 - 04:49 PM

Are the latest files in Mercurial's local repositories saved in their original file format or a special format / archive? What about SVN? What about git?

I don't know about Mercurial. SVN usually stores deltas for text files. Git for the most part stores zlib compressed files.
 

If I wanted to manually modify the up-to-date repository without invoking any version control tool or command, which ones permit me to do so?

Very few, and getting smaller. VCSs are tending towards more sanity checks to detect corruption, which is what manual attempts to modify the repository will look a lot like. On the plus side, they are also tending towards more automatic tracking of moved files. Ex: with git you can rearrange your working copy how you like, stage all the changes, commit and it will usually be able to figure out which files were moved and be able track history across that. If you wanted you could do it all with a single command, though I prefer to separate stage and commit.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS