Announcement

Collapse
No announcement yet.

version control

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    version control

    what is the recommended and useable version control that can be used with udk development(version control for udk editor, not visual studio)?

    from what i understand,
    1. perforce is supported
    2. alienbrain is supported and documented by epic

    are there any support for free version control system, like subversion and mercurial natively in udk?

    if there is, how to integrate? when i enable version control in udk, only perforce scc login is visible and i cant find any way to change it to any other scc.

    thanks.

    #2
    There is some kind of plugin for Tortoise that will enable whatever API it is that the editor wants to use, I tried one out, but it was oppressively difficult to do anything with, and it really ****** me off to no end. There were a few others, but I figured i'd just continue using Tortoise as normal, without using the built in editor support.

    Comment


      #3
      You can download a free copy of Perforce that works for two users.

      Link

      Comment


        #4
        Originally posted by Mr. Smith View Post
        You can download a free copy of Perforce that works for two users.

        Link
        a version control limited to 2 user is not very practical for development(for evaluation maybe). thanks for the heads up anyway.

        so does this mean, it is impossible for udk to support other version control other than perforce?

        thanks.

        Comment


          #5
          There's no version control that you can use integrated into UDK. Most development teams are likely to use SVN. Two of the three teams I am currently involved with do; and the third will in future, it just isn't necessary yet.

          Comment


            #6
            a version control limited to 2 user
            and five client workspaces

            You can use an only user and work 5 peoples.

            Comment


              #7
              Originally posted by erwilly View Post
              and five client workspaces

              You can use an only user and work 5 peoples.
              i dont understand. 2 user. 5 client workspace. 5 people.

              what?

              Comment


                #8
                Perforce client programs manage files in a designated area of your local disk, called your client workspace. Your client workspace is where you will be doing most of your work.
                The free version have 5 client workspaces.

                Comment


                  #9
                  I think he means 5 "projects" yeah - client workspace = buzzword for projects?

                  Comment


                    #10
                    I think he means 5 "projects" yeah - client workspace = buzzword for projects?
                    no, client workspace = client workspace

                    Comment


                      #11
                      ok. i still dont understand.

                      how many people can work on single project?

                      Comment


                        #12
                        Five, and As Far As I Know, you can create unlimited projects.

                        Comment


                          #13
                          I'm using visualsvn and tortoise svn on client platforms. I've been digging around for any info on content browser integration, but only perforce is supported atm. Still, using explorer for assets and visual studio for script seems to be an ok pipe for the time being, but I do get nervous with svn handling all the content binaries since it's not really intended for it. Has anyone had any issues with large binaries, like .max, .psd etc., in svn? Or is it just, how you say, paranoy?

                          Comment


                            #14
                            There's basically two things you need to worry about -- other people writing to the files at the same time you are writing to the files, and the overall size of the SVN. The first is handleable by using locks properly and communicating with everyone decently. The second is just something that's going to happen, and you're probably going to want to keep your filesizes somewhat smallish -- when you make a change to a 100mb binary, everyone gets to redownload that binary pretty much, so you don't want packages that are rapidly changing (as in early development stages) to become too huge.

                            Comment

                            Working...
                            X