• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
buumchakalaka

Version control for begginers

44 posts in this topic

Do not make the mistake of using GIT as your first source control.

I use it at work, it's very powerful, but it takes a long time to understand.

If you have a small project (~5 people) , there is no need for distributed source control. It just complicates everything.

 

I can make the following recommendations: 

1. Use SVN

2. Use it from a GUI ( you'll understand stuff way faster then command line )

 

If you're using windows: Download Tortoise SVN and create a local repository.

If you want to upgrade to a server-client setup: Download Visual SVN server,.

 

Use GIT once you are working on giant project with several remote work - sites (e.g. Compiling a Linux Kernel) .

Using it for a small project is just looking to complicate things. Also, many SVN concepts can serve as an intro to GIT (commit,checkout,branch,merge, diff,patch, etc...) . 

1

Share this post


Link to post
Share on other sites

[quote name='Robot Ninja' timestamp='1358708069' post='5023574']
The nice thing about Git too is that you can keep a local repository if you don't want/can't get an online one
[/quote]

[quote name='Cornstalks' timestamp='1358727696' post='5023692']
No need for a server/internet connection; you can commit, do diffs, or view the log all on your local system
[/quote]

As mentioned before, you can use Subversion on your computer without having to install a server. Especially with TortoiseSVN it is a matter of less than 10 clicks.

 

[quote name='Cornstalks' timestamp='1358727696' post='5023692']
With centralized version control systems (a la SVN), you've got one place you push and pull your updates to and from, which means I can't push/pull to/from different partitions or other computers like I can with git.
[/quote]

Why not setup your own server and do all your source control on it? I found it quite easy to do.

I already had a server in a data center (for email, ftp, http, ... so adding version control was only logical) and it is not very expensive (something like 34€/45$ /month), besides you do get a much better connection than you can get with your home broadband.

 

[quote name='wintertime' timestamp='1358714283' post='5023612']
wouldnt use SVN anymore. Mercurial(hg) and git are the modern things.
[/quote]

Could you elaborate what features you do require that subversion doesn't support?

Scala is more modern than C, still I wouldn't force my worst enemy to only code in Scala. Well, maybe...

 

One more question, do you use some explorer integration? I haven't found one that is comparable with TortoiseSVN which was always a bit of a show stopper. Maybe you can recommend one (for Windows).

 

[quote name='3Ddreamer' timestamp='1358716783' post='5023626']
Can any of these control software be used by someone who knows little about IT and in particular game development? The reason I ask is that I know someone who is thinking about starting a company to make software. Should he just leave the version control to someone else such as the lead programmer or could he use any of this software mentioned here? The company head uses windows and would need a very user friendly sv system, so what should I recommend?
[/quote]

I'm using Subversion (TortoiseSVN) myself and recommended it to my sister to keep a history of her LaTeX documents. She's a nurse and no computer nerd. She does get along well for her own stuff, since she couldn't convice any of her colleagues to use it there are hardly any conflicts to resolve.

 

However I believe if someone is able to handle his own documents, organizing them in directories, it should be no problem to learn to use SVN even in a more complicated environment. Note: If he/she is having trouble creating/moving/editing/deleting files and folders or if he/she is unable or unwilling to read a manual it's probabably not a good Idea to use make him/her use any version control system.

 

If you mean with "Should he just leave the version control to someone else such as the lead programmer" that the lead programmer should set it up and maintain it, I would say it depends. Many programmers are able to do it, however programmers aren't administrators. There is no guarantee that the programmer is able to do it. Besides maybe the programmer is not willing to do it (he became a programmer not a server admin for a reason). And then there is the cost factor, maybe a sysadmin is cheaper than a developer, then the developer shouldn't be doing it. And ne more important thing, don't give this responsibility to your lead, he has already much to do, give it to a specialized tool guy/the sysadmin/someone else, make sure he has enough time so he can still do his usual tasks.

 

Actually using the version control system is a task for everyone that is working with the version controlled files. If you put you source code in, all developers need to use it. If you put your assets in, all artist and designers need to use it. In addition some other people might need it, project managers, qa, ...   All of those people have to be tought using the system. Don't assume that every developer you hire has already worked with your system. Make sure they really understand what does what, else they will create a mess and you will waste time cleaning up after them.

1

Share this post


Link to post
Share on other sites

No need for a server/internet connection; you can commit, do diffs, or view the log all on your local system

 

As mentioned before, you can use Subversion on your computer without having to install a server. Especially with TortoiseSVN it is a matter of less than 10 clicks.

Sure, but my point was that I can have both a server that I push to and still do all that I need to without an internet connection. Maybe "no need for a server" wasn't the best way to say it and I should've just stuck with "no need for an internet connection."

 

With centralized version control systems (a la SVN), you've got one place you push and pull your updates to and from, which means I can't push/pull to/from different partitions or other computers like I can with git.

 

Why not setup your own server and do all your source control on it? I found it quite easy to do.

I did, but sometimes my internet dies or I'm programming in various places and don't have an internet connection. The lack of internet connection limits me in no way from my development though (at least from the SCM perspective). It's particularly nice when working on different partitions with no internet connection.

Edited by Cornstalks
1

Share this post


Link to post
Share on other sites
Simply learn both SVN and Git. I'd highly recommend learning SVN first, due to Git's steep learning curve. SVN will give you a decent understanding of VCSs in general quickly, after which you can hop into more advanced topics. I personally first hated Git when I tried to learn (and am still learning...) it after SVN, but once I got some sort of hold of it, I realized there's no going back (to SVN). As your focus is in making games, you probably end up using SVN more, assuming you will work with not-so-tech-savvy people (artists etc.). If you can, use TortoiseSVN and TortoiseGit - they'll make your life a lot easier. Edited by Stinkfist
2

Share this post


Link to post
Share on other sites

I'm curious to what extent these version control systems apply to very new developers/programmers, like me.  I'm in the very early stages of my 3rd game project (a space invaders clone) and I've decided to plan and control my process a bit more than I did in the first 2 projects.  I have a list of modules I'll need, I pick a set to put into the next revision, and then copy the last revision and give it a new rev number.  All of the coding is done from the same location, a flash drive I carry with me.

 

On the one hand, version control software is clearly widely used, so getting a good handle on it would be wise.  This thread demonstrates that, as does browsing jobs on craigslist.  Folks there often request links to work you've done, or a link to your git.  So, when the time comes to look for programming jobs in a couple of years, it would be good to be able to show that I'm familiar with version control.

 

On the other hand, there's quite a lot of other stuff that beginners also need to be learning.  If we try to add everything we need to learn in at once we'll get way too bogged down with getting a handle on new interfaces to ever learn and code anything.  Also, when I research version control most of the features they talk about are designed to make things work better for projects with multiple people modifying the code base.

 

Do these version control software set-ups offer more for projects with a single programmer that would make them more useful for a beginner to learn sooner rather than later?  As it stands I plan to see how my simple revision rolling method works for this project, and then hopefully move into one of the more formalized version control programs for the next project, which will be my first somewhat original game.  If SVN or git or one of the others simplify more of the process, though, it would be worthwhile to go ahead and learn it now.  Do the features available for solo programmers justify the learning curve needed?

0

Share this post


Link to post
Share on other sites
Do these version control software set-ups offer more for projects with a single programmer that would make them more useful for a beginner to learn sooner rather than later?

I would say yes. You don't have to become a version control ninja (just the basics should be good enough at first), but simply checking in your code as you develop will allow you to rewind if you totally f*** things up and need to undo a series of changes you made because you realize it's just not working this way. Beginners do that a lot smile.png

 

But even if you don't need to rewind back to a previous state, I think it has the added benefits that a) you get to learn a tool that you'll use for the rest of your life (even if you change between git/SVN/etc. the idea of SCM stays the same), and b) it forces you to stop and think "is this something I really want to check in?" It's a kind of self-sanity check. Sometimes I've written a quick, terrible hack, and then when I went to check in my code I had to stop and think about whether or not I felt okay checking such horrible code, and decided to write a proper fix and check that in. In other words, it can help breed good habits.

 

You won't die if you don't use it. You don't need to spend a lot of time on it. But it's got a few benefits.

Edited by Cornstalks
2

Share this post


Link to post
Share on other sites
Do these version control software set-ups offer more for projects with a single programmer that would make them more useful for a beginner to learn sooner rather than later?

I would say yes. You don't have to become a version control ninja (just the basics should be good enough at first), but simply checking in your code as you develop will allow you to rewind if you totally f*** things up and need to undo a series of changes you made because you realize it's just not working this way. Beginners do that a lot smile.png

 

Hehe, good point.  I wouldn't necessarily need to master the whole thing, just get a handle on the basic stuff.  And I can attest that being able to rewind would be nice, because I f*** things up plenty.

0

Share this post


Link to post
Share on other sites
Two important advantages [...] over their last-century forebears like SCCS, RCS, CVS, SVN, VSS, etc. are this.

(1) atomic commits
(2) branching speed
(1) No advantage. Why? Because contrary to Git propaganda, all commits in Subversion are atomic. A commit in Subversion succeeds or fails. There is no in-between.

(2) Not relevant. Why? Because contrary to Git propaganda, branching in Subversion is very fast.

Do note that most of this propaganda was written by someone who openly admitted that he never even looked at Subversion based on a sentence containing the word "RCS" that he picked up somewhere and didn't understand properly. And, his fanboys.

These claims are simply untrue.

EDIT: Note that for example the GCC project uses Subversion. If branching or working with hundreds of developers was really that forbidding, then honestly I wonder how they're doing it.

Since when wholesale copying of an entire source tree from trunk to a branch, which is how Subversion implements branching, has become "very fast"? Maybe you are working on toy-size projects.

Subversion atomic commits either succeed or leave your local metadata corrupted. Not a good deal; Git is more robust.

 

Apart from these low level details, Subversion has deep issues, for example being able to take arbitrary revisions and branches as a reference for each file. When you update, you need to be aware of all stuck files, or the message that all your working copy is up to date becomes a dangerous lie.

1

Share this post


Link to post
Share on other sites

Two important advantages [...] over their last-century forebears like SCCS, RCS, CVS, SVN, VSS, etc. are this.

(1) atomic commits
(2) branching speed

(1) No advantage. Why? Because contrary to Git propaganda, all commits in Subversion are atomic. A commit in Subversion succeeds or fails. There is no in-between.
 


No, svn commits are not atomic. I can commit a set of changes to git/hg/bzr/darcs as one single atomic operation, and then uncommit/revert in one single atomic operation, or cherry-pick and apply in one single atomic operation. If I'm using svn and commit a changeset of say 20 files, then I get 20 single commit operations. If I want to revert, I can perform 20 separate reversion operations. Cherry-picks aren't really possible, although I could theoretically check out two trees using the appropriate RIDs, use a modern diff tool to generate a patchset, then apply it manually and commit.

It is definitely an advantage to be able to use your source control to do merges and recovery.
(2) Not relevant. Why? Because contrary to Git propaganda, branching in Subversion is very fast.
Contrary to unsupported assertions, branching in svn is painfully slow. Like I said, we would freeze our codebase for up to 48 hours while branching took place. The freeze is necessary because of the non-atomic nature of SVN: if a developer checks in a change during the lengthy branch process you can end up with an out-of-synch branch. Of course, this was profession production software with many hundreds of thousands to lines of code, maybe millions, and thousands of source files. If you have a toy project or a small hobby project that's never going to get released, this may not be a consideration for you.
Do note that most of this propaganda was written by someone who openly admitted that he never even looked at Subversion based on a sentence containing the word "RCS" that he picked up somewhere and didn't understand properly. And, his fanboys.

These claims are simply untrue.
I back up my claims with experience. I used SCCS when it came out, I used its successor RCS when it became available. I used CVS for years and quickly switched to SVN when it became stable enough. I've also used VSS, Perforce, and a few other commercial VCSes. I've used git for Linux kernel maintenance (hardly a trivial project) as well as many other projects. I use bzr every day for major professional projects.

I make my assertions based on observed, experienced facts. Nothing else. SVN does not have atomic commits. Branching in SVN is several orders of magnitude slower than git.
EDIT: Note that for example the GCC project uses Subversion. If branching or working with hundreds of developers was really that forbidding, then honestly I wonder how they're doing it.
I'm a GCC maintainer. It uses SVN. Branching is rare because it's very slow. Merges from development branches are slow and tedious because SVN does not support atomic commits or cherry-picking. Many developers use the git-svn front end to overcome these problems.
0

Share this post


Link to post
Share on other sites

[quote name='shadowomf' timestamp='1358804132' post='5024044']
Could you elaborate what features you do require that subversion doesn't support?



One more question, do you use some explorer integration? I haven't found one that is comparable with TortoiseSVN which was always a bit of a show stopper. Maybe you can recommend one (for Windows).
[/quote]

I'm using TortoiseHG which is very easy to install and use, though I have the habit of often just typing in the commands in the commandline because they are so easy. SVN always needs to connect to the server, you just have the last version locally. For SVN I just have a command line tool installed and only use it when I need to.

With a DVCS you always have a copy of the whole history on your computer, can easily make as many repositories as you like so you are less likely to need to cram everything into one huge repository, clone them very fast for experimenting, commit or revert or update to any version locally even without internet connection and only push to the server when you are sure its ready, easily push on your USB-stick or really anything for backup or taking it with you.

0

Share this post


Link to post
Share on other sites

In a nutshell, what are the best open source version control programs?

I'd say the biggest are SVN (for central) and git or hg* (for distributed). They're at least the most common/popular. Asking for what the "best" is is a loaded question, as they're tools that have similar functionality but are fine tuned for different needs or use cases.
 
*The main reason I prefer git over hg is because a) git is easier/simpler/faster to say (than "hg" or hg's proper name) and b) I'm not sure how to spell hg's proper name so I never use it, hence I'm awkwardly saying "hg's proper name" tongue.png

0

Share this post


Link to post
Share on other sites
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?
 
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?
 
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, so I always returned to ye ol' manual zipping up the entire directory and renaming it to the current date, then TeraCopying it to other networked machines for safety. I really want, and recognize the need, to learn at least one of the major source control systems, but haven't had the time to learn and customize them to keep my project mine and not theirs.
 
As an analogy, I also don't like iTunes and Windows Media, for how they take over and 'organize' your music files for you - and spend alot of time crawling my computer looking for new files without being prompted to. So I organize my own music files in their folders how I choose, and I use a media player that works with me instead of takes control away from me. (I use foobar2000, if anyone was wondering)
 
What source control system works best with a lazy finicky micro-managing NIH nitpicking solo-programmer who-wants-files-local-and-unobfuscated like myself? smile.png Edited by Servant of the Lord
0

Share this post


Link to post
Share on other sites

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.
1

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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
2

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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.
1

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0