Version Control Questions Megathread (SVN / git / whatever else)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

sonic bed head posted:

I am pretty sure that your understanding of what svn:ignore does is incorrect. svn:ignore has nothing to do with the repository/server. It is just a setting that tells the client to ignore that directory when updating/committing.

Incorrect. Subversion always notices changes to its versioned objects. If something is in the repository, the svn:ignore property doesn't do a drat thing. It only tells the client to ignore new, unversioned objects that have been created.

I can't guess what's happening with epswing, though.

# ? May 28, 2009 17:06

Adbot: ADBOT LOVES YOU

# ? Apr 18, 2024 21:49

epswing: Nov 4, 2003; Soiled Meat

Lysidas posted:

It only tells the client to ignore new, unversioned objects that have been created.

Yes, exactly.

This is really weird. I might create a little screen recording of this in action. I've used svn for years, and I haven't seen this behavior before.

# ? May 28, 2009 17:15

Ferg: May 6, 2007; Lipstick Apathy

So I'm aware that msysgit is somewhat buggy in comparison to it's UNIX counterpart, but I'm not sure if msys is to blame for this issue or if I'm just an idiot:

Assume I have branch master, development and release. If I have development checked out, and do a

code:

$ git pull origin some_new_feature

it pulls and merges with my current branch. However, when I then perform the merge and make any necessary commits, I think go and checkout the release branch.

Now I'm in the release branch and do a

code:

$ git status

and what is there? The exact same pull from some_new_feature I just did in the development branch. It shows up as a list of modified files in every single branch I checkout until I've merged it everywhere.

I blame msysgit because I haven't been able to replicate this on my Linux setup that I use at home. Is this a common issue? It's loving annoying.

# ? May 28, 2009 21:04

FigBug: Apr 27, 2002; Lemon Party - Lest we Forget

A while ago I saw an ad for a product that was aimed at management. It was a tool that you connect to subversion and it tells you which of your employees are working hard, how much they are doing, etc. The idea was that you could promote/fire people based on the output of this tool. It sounded hilarious, and now I want to try it, but I can't remember what it was called. Anybody know what I'm talking about?

# ? May 29, 2009 19:08

sonic bed head: Dec 18, 2003; this is naturual, baby!

If I have a working copy checked out with local changes, is it possible for me to copy that working copy to make a pristine, non changed copy locally? I am trying to have two different copies of the same branch, but I don't want to go through checking it out again because it's huge and will take 45 minutes on my slow internet connection. I also don't want to revert my current working copy. Thanks.

# ? Jun 4, 2009 20:23

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

sonic bed head posted:

If I have a working copy checked out with local changes, is it possible for me to copy that working copy to make a pristine, non changed copy locally? I am trying to have two different copies of the same branch, but I don't want to go through checking it out again because it's huge and will take 45 minutes on my slow internet connection. I also don't want to revert my current working copy. Thanks.

I assume you're using SVN. Copy the directory, then revert changes in the copy.

# ? Jun 4, 2009 20:35

Filburt Shellbach: Nov 6, 2007; Apni tackat say tujay aaj mitta juu gaa!

I just converted nearly all of my repositories to git. :sigh:

# ? Jun 4, 2009 20:45

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Sartak posted:

I just converted nearly all of my repositories to git.

my condolences

# ? Jun 4, 2009 21:04

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

Sartak posted:

I just converted nearly all of my repositories to git.

I am working on this right now, with an svn frontend so our retarded multi-thousand-dollar project management crapware can see it.

# ? Jun 4, 2009 23:12

nobleclem: Apr 13, 2005; HOW MANY RED TITLES DO I HAVE TO HAND OUT BEFORE YOU PEOPLE LEARN TO STOP CLOSING THREADS IN SH/SC?

We use SVN and I would consider moving us to git however two things keep me from pushing it... 1) Server Admins, 2) No good mac GUI's for the designers.

Just today a designer updated a file and pushed it into production however this file was updated for a major change before she made her update. So that change was not done and well it broke some poo poo. So I had to find and revert the file. Now what would be nice is to be able to utilize branches. I think git would work better for our environment but would need to run some tests.

Ahh the joys of working with those who use the other side of their brain.

# ? Jun 5, 2009 05:42

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

nobleclem posted:

We use SVN and I would consider moving us to git however two things keep me from pushing it... 1) Server Admins, 2) No good mac GUI's for the designers.

Just today a designer updated a file and pushed it into production however this file was updated for a major change before she made her update. So that change was not done and well it broke some poo poo. So I had to find and revert the file. Now what would be nice is to be able to utilize branches. I think git would work better for our environment but would need to run some tests.

Ahh the joys of working with those who use the other side of their brain.

at least gitX is 10x better than svnX.

For us we can't get Versions because one of the reasons they let us switch to something not absolutely poo poo (that we pay thousands for) is because we promised it'd cost nothing.

# ? Jun 5, 2009 06:28

nobleclem: Apr 13, 2005; HOW MANY RED TITLES DO I HAVE TO HAND OUT BEFORE YOU PEOPLE LEARN TO STOP CLOSING THREADS IN SH/SC?

deimos posted:

at least gitX is 10x better than svnX.

For us we can't get Versions because one of the reasons they let us switch to something not absolutely poo poo (that we pay thousands for) is because we promised it'd cost nothing.

Our designers use Version however they seem to be bitching about it for some reason. I have never used it. One of the junior devs set them up with the software. I think one case is that its slow.

But I agree svnX sucks hard core.

# ? Jun 7, 2009 06:07

Argue: Sep 29, 2005; I represent the Philippines

We have an svn repo with 4000 commits, and I've been using git svn for it from the start. My other teammates have only discovered git recently, so we're trying to figure out the best way for them to set up the project under git. We have two options; the first is to check out the project using git svn. Since there are 4000 commits in the repo, we wouldn't be able to check it out in a reasonable amount of time without nuking most of the history. On the other hand, they could clone my repo, but in that case, the svn info would be lost, and it's a huge pain adding svn info when a project wasn't checked out with git svn from the start.

Is there some way to combine the two so that we can preserve the history and still have the svn info?

# ? Jun 8, 2009 07:34

Fullets: Feb 5, 2009

Argue posted:

We have two options; the first is to check out the project using git svn. Since there are 4000 commits in the repo, we wouldn't be able to check it out in a reasonable amount of time without nuking most of the history.

FWIW, checking out our 16000-revision SVN repo via git svn takes around 70 minutes - sure, it's not quick, but I've found that it's something I only need to do once; git svn'ing your project might take less time than you fear.

Alternatively, the git-svn man page has this in it, which sounds a lot like it'll let you push/pull changes from svn:

git svn --help posted:

The initial git-svn clone can be quite time-consuming (especially for large Subversion
repositories). If multiple people (or one person with multiple machines) want to use git-svn
to interact with the same Subversion repository, you can do the initial git-svn clone to a
repository on a server and have each person clone that repository with git-clone:

# Do the initial import on a server
ssh server "cd /pub && git svn clone http://svn.example.com/project
# Clone locally - make sure the refs/remotes/ space matches the server
mkdir project
cd project
git init
git remote add origin server:/pub/project
git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch
# Create a local branch from one of the branches just fetched
git checkout -b master FETCH_HEAD
# Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on serve
r)
git svn init http://svn.example.com/project
# Pull the latest changes from Subversion
git svn rebase

I'm not sure if this is the huge pain you're referring to, as it looks easy but I screwed something up when I tried it a while back.

# ? Jun 8, 2009 12:57

Filburt Shellbach: Nov 6, 2007; Apni tackat say tujay aaj mitta juu gaa!

You can also use git svn fetch -r3950 to treat everything before the first 3950 commits as one huge commit, which is fast.

# ? Jun 8, 2009 21:11

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Reasons You Don't Make A Zero-Experience-In-CM Software Developer Do Clearcase Stuff, #33

Me: "clearfsimport? You telling me I DIDN'T have to do those 300+ checkins/diffs by hand, one at a time? :suicide:

# ? Jun 13, 2009 00:37

uXs: May 3, 2005; Mark it zero!

Question on Mercurial:

At some point in the past, I switched from SourceSafe to Git for a project. I didn't convert the repository, I simply turned off the SourceSafe binding, threw away the .ssc files, and created a new Git repository.

I now can't stand working with SS any more, so I'm going to push for a switch to Mercurial. (Windows support in Git isn't good enough.) I've tested Mercurial for some other projects and it looks fine. (I only used Git for this one project because I really need something that could branch and merge easily.)

Now I have a problem though: I want to convert the SourceSafe projects to Mercurial projects. For most projects that are still in SourceSafe, it'll be easy: just run the conversion script and we're done.

For the project I mentioned above though, it's not that easy. I basically have a repository A, converted from SourceSafe, with all the history up to 3 months ago. Then I have another repository B, converted from Git, with history from 3 months ago until today. I there some way to stitch both of them together ? I basically want to say: "revision 1 from repository B now has revision 927 from repo A as a parent", without having to resolve any conflicts. Any ideas how to do this ?

# ? Jun 17, 2009 17:58

uXs: May 3, 2005; Mark it zero!

uXs posted:

...

I basically want to say: "revision 1 from repository B now has revision 927 from repo A as a parent", without having to resolve any conflicts. Any ideas how to do this ?

I found how to do this with some help from the mercurial mailing list:

a) Make a new repository ('merged'), and pull both repositories. (The second pull will require an -f switch because they're unrelated.)
b) Find the full 40-character long revision keys for the revisions that you want to stitch together. These can be found in the shamap file. Put them in a text file on one line (separate with a space), with the revision that is going to become the child first, and the parent revision second.
c) run the command 'hg convert merged really_merged --splicemap splice.txt'. (You'll need the convert extension enabled for this.) This will make a repo 'really_merged' that is really merged.

# ? Jun 20, 2009 11:58

jayhat: Feb 27, 2008

Just want to know one thing - is there any reason why perforce costs so much?
I've never had a chance to try using it, but it better do something special to cost so much when up against so many awesome, free alternatives.

# ? Jun 20, 2009 14:22

very: Jan 25, 2005; I err on the side of handsome.

jayhat posted:

Just want to know one thing - is there any reason why perforce costs so much?
I've never had a chance to try using it, but it better do something special to cost so much when up against so many awesome, free alternatives.

Because companies like to pay for things. This is all I can come up with.

# ? Jun 20, 2009 20:08

hey mom its 420: May 12, 2007

That is actually literally true. Many companies, when faced with two products that are equivalent, will pick the one that they have to pay for, sometimes even if the free one is better. It's a culture thing I guess. Also a stupidity thing.

# ? Jun 20, 2009 20:41

king_kilr: May 25, 2007

Allegedly it scales better to super large repos. I can only assume companies have ridiculously large repos as we know something like Git must be able to handle at least the size of Linux or GNOME.

# ? Jun 20, 2009 20:51

POKEMAN SAM: Jul 8, 2004

jayhat posted:

Just want to know one thing - is there any reason why perforce costs so much?
I've never had a chance to try using it, but it better do something special to cost so much when up against so many awesome, free alternatives.

Perforce really is great. I mean, it's intuitive enough for non-programmers to use without screwing anything up, has a multitude of options to help with huge repositories (like flagging a file such that you only want to keep the last 3 revisions for large binaries and such) has an API that you can use to quickly get Perforce functionality into your applications, and a whole lot more.

I didn't know how great Perforce was until I spent 3 years using it, and there are still some pretty cool features that I learn about once in a while.

Also it's free for 2 users, so it works great for personal projects as well.

# ? Jun 20, 2009 21:23

ehnus: Apr 16, 2003; Now you're thinking with portals!

king_kilr posted:

Allegedly it scales better to super large repos. I can only assume companies have ridiculously large repos as we know something like Git must be able to handle at least the size of Linux or GNOME.

To be honest Linux and GNOME aren't that large. My company uses Perforce and the average depot size is in the 90-100GB range (ie: if you sync, you'll copy over 90GB of data to your local machine, repository size including revisions is well into the terabytes), mostly binary data, and Perforce handles it surprisingly well.

Like Ugg Boots said it's also pretty easy to use, and it's pretty easy to integrate into tools from an API point of view. If I recall it's also free for open source projects, and there are a few out there currently using it, like FreeBSD.

# ? Jun 20, 2009 22:44

krysmopompas: Jan 17, 2004; hi

ehnus posted:

To be honest Linux and GNOME aren't that large. My company uses Perforce and the average depot size is in the 90-100GB range (ie: if you sync, you'll copy over 90GB of data to your local machine, repository size including revisions is well into the terabytes), mostly binary data, and Perforce handles it surprisingly well.

Similar situation - we've got about a 115gb depot on one project, mostly binary, with around 180 users hitting it. There are also 4 build machines constantly running and checking in ~500mb of compiled exe and script every 15 minutes to 2 hours.

We've probably got over a dozen p4 proxies set up to handle the load, and aside from someone's dumbass move of not having enough hd space on all of the proxies, it seems to be handling it. Occasionally a proxy fails without any good explanation, but the worst consequence is that an autobuild fails or you have to flush your dns cache and restart p4win.

# ? Jun 21, 2009 22:08

MononcQc: May 29, 2007

A question about Mercurial here.

I have a repo with many levels for more than one use that may look like that

code:

base
 !- docs
    !- en/
    !- fr/
 !- sites
    !- some site/
       !- static
       !- src
    !- another site/
       !- static
       !- frontend
       !- backend
          !- src/
          !- tests/

say I want to only change the stuff from sites/some site/src/.../whatever.ext. Is there any way I could only check-out/clone a single subdirectory of the whole repo? SVN or CVS would make this pretty easy, but it doesn't seem possible in mercurial. Is there any way to do it or is my best option to try and migrate to another DVCS that would let me do it?

EDIT: guys from #mercurial on freenode redirected me to http://mercurial.selenic.com/wiki/subrepos which should do the job.

MononcQc fucked around with this message at 19:51 on Jul 5, 2009

# ? Jul 5, 2009 19:41

crazyfish: Sep 19, 2002

MononcQc posted:

A question about Mercurial here.

I have a repo with many levels for more than one use that may look like that
code:
base
 !- docs
    !- en/
    !- fr/
 !- sites
    !- some site/
       !- static
       !- src
    !- another site/
       !- static
       !- frontend
       !- backend
          !- src/
          !- tests/
say I want to only change the stuff from sites/some site/src/.../whatever.ext. Is there any way I could only check-out/clone a single subdirectory of the whole repo? SVN or CVS would make this pretty easy, but it doesn't seem possible in mercurial. Is there any way to do it or is my best option to try and migrate to another DVCS that would let me do it?

EDIT: guys from #mercurial on freenode redirected me to http://mercurial.selenic.com/wiki/subrepos which should do the job.

I'm curious as to why you would want to use a single repo for multiple sites. Is there some common shared codebase or other set of dependencies between them? If there isn't, I would venture to say that you should probably just use multiple repos.

# ? Jul 10, 2009 20:46

sklnd: Nov 26, 2007; NOT A TRACTOR

krysmopompas posted:

Similar situation - we've got about a 115gb depot on one project, mostly binary, with around 180 users hitting it. There are also 4 build machines constantly running and checking in ~500mb of compiled exe and script every 15 minutes to 2 hours.

We've probably got over a dozen p4 proxies set up to handle the load, and aside from someone's dumbass move of not having enough hd space on all of the proxies, it seems to be handling it. Occasionally a proxy fails without any good explanation, but the worst consequence is that an autobuild fails or you have to flush your dns cache and restart p4win.

What's the point of storing builds in source control versus just using the file system?

# ? Jul 11, 2009 05:02

Rapportus: Oct 31, 2004; The 4th Blue Man

sklnd posted:

What's the point of storing builds in source control versus just using the file system?

In my work's case, in Operations we gain the benefit of guaranteeing consistency and versioning by using perforce to house and transport our builds. Distributing a build from one site to another is an atomic operation with perforce, either the whole thing submits or it fails. Using a file system + rysnc type of housing/transport, it takes more work to track issues and has less flexibility compared to what perforce could provide out of the box.

# ? Jul 11, 2009 05:29

sklnd: Nov 26, 2007; NOT A TRACTOR

Seems like a lot of overhead for what you could achieve with tar, scp, and md5sum.

# ? Jul 11, 2009 05:34

krysmopompas: Jan 17, 2004; hi

sklnd posted:

What's the point of storing builds in source control versus just using the file system?

There isn't. Some fuckhead in charge wanted it that way, so it's that way.

# ? Jul 11, 2009 06:24

sklnd: Nov 26, 2007; NOT A TRACTOR

Haha that sounds more like the proper speed of things.

# ? Jul 11, 2009 13:05

MononcQc: May 29, 2007

crazyfish posted:

I'm curious as to why you would want to use a single repo for multiple sites. Is there some common shared codebase or other set of dependencies between them? If there isn't, I would venture to say that you should probably just use multiple repos.

Not my choice of structure.

# ? Jul 12, 2009 02:49

Rapportus: Oct 31, 2004; The 4th Blue Man

sklnd posted:

Seems like a lot of overhead for what you could achieve with tar, scp, and md5sum.

It's more useful for 3rd party and non-technical drops. Instead of providing a list of protocols/procedures to follow its easier to roll up the drop into one user-friendly p4 submit and be done with it.

# ? Jul 13, 2009 08:57

BizarroAzrael: Apr 6, 2006; "That must weigh heavily on your soul. Let me purge it for you."

I'm new to managing SVN so I hope you don't mind me asking something I might find in the course of reading the Red Bean book.

We run SVN updates on most machines overnight to keep them current, but some things rarely need updating and some teams don't need certain files updated for the course of their own work, and so we would like to save time and network resources for the update by having SVN leave them as they are.

If I understand right, since these are versioned files I can't use SVN:Ignore for this. Is there a solution other than replacing the SVN update command for the whole project with many smaller commands to update bits of it at the exclusion of the offending files?

# ? Aug 3, 2009 10:44

tef: May 30, 2004; -> some l-system crap ->

http://svnbook.red-bean.com/en/1.0/ch07s03.html

# ? Aug 3, 2009 10:49

MonkeyMaker: May 22, 2006; What's your poison, sir?

Didn't see this posted on the last page or so. Pro Git, new book, available for free online: http://progit.org/book/

# ? Aug 3, 2009 15:04

BizarroAzrael: Apr 6, 2006; "That must weigh heavily on your soul. Let me purge it for you."

tef posted:

http://svnbook.red-bean.com/en/1.0/ch07s03.html

I'm not sure this is what I'm after, it appears to let me have parts of the project sync with different locations, rather than not sync at all.

To elaborate, I would like to have something on the clients side that stops certain folders and files in the Local Copy being updated when SVN update is run on the whole project.

# ? Aug 5, 2009 17:33

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

BizarroAzrael posted:

I'm not sure this is what I'm after, it appears to let me have parts of the project sync with different locations, rather than not sync at all.

http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html

quote:

Finally, there might be times when you would prefer that svn subcommands would not recognize, or otherwise operate upon, the external working copies. In those instances, you can pass the --ignore-externals option to the subcommand.

# ? Aug 5, 2009 17:40

Adbot: ADBOT LOVES YOU

# ? Apr 18, 2024 21:49

BizarroAzrael: Apr 6, 2006; "That must weigh heavily on your soul. Let me purge it for you."

Avenging Dentist posted:

http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html

It appears that can only be applied to stuff not already in the repository. The files are already present and necessary, and I don't want to have to remove them on so many machines for the sake of this.

What if I remove, backup or otherwise disable the .SVN folder in directories (or is it the parent directories?) of files that I want to go un-updated? I could have a script that renames or moves the .SVN folders and then puts them back after the update.

Edit: No it won't, Windows won't let me rename a folder back to .svn and running SVN update with a missing one will make it demand a cleanup first.

BizarroAzrael fucked around with this message at 12:39 on Aug 6, 2009

# ? Aug 6, 2009 12:27

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »