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)

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"

Bazaar has some very nice documentation, much of which is useful with other (D)VCS as well. Bazaar in five minutes and the user guide are worth a look.

Also, considering how large IBM is, I'm always surprised at how terrible their VCS tools (ClearCase and Continuus) are.

# ¿ Apr 8, 2009 22:11

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 07:09

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"

SAHChandler posted:

I recently got into a debate with a friend of git v. bzr.

I did some research, but can anyone tell me (other than an "easier" to use interface, as to why I would want to use bzr over git?

It's got a stable API, so instead of having to write extensions by parsing output from other commands, you just import bzrlib.

You can give each branch its own directory, so generated temporary files won't get mixed up between branches.

It tracks file renames, which is *very* useful for versioning non-text (images, compressed files, external libraries, etc).

It works well on Windows, without having to install a Linux emulation layer, and comes with a GUI if that's your bag.

# ¿ Apr 16, 2009 21:54

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"

bitprophet posted:

Can't comment on the rest (besides making a snide "who gives a poo poo about Windows?" taunt, and mention that Mercurial is supposed to have good Windows support too) but Git tracks file renames just fine, as far as I can tell?

Git only tracks file contents, so when a binary file is both renamed and modified, it's usually treated as a completely different file. This can make it difficult to track things like "who added this image to the project?".

# ¿ Apr 17, 2009 02:24

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:

That this is the first mention of darcs makes me sad.

misery.sh

# ¿ Apr 17, 2009 02:53

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"

king_kilr posted:

This is terrible, that means when I'm doing development of say, Django, I'd need to muck with my python path since the location of my code would change. Learn to manage your own files properly, I've never once had this temporary files issue.

You don't have to put them in different directories -- you can always just use the Git way where everything's mashed into one directory, if you want.

Using your Django example, how do you manage changes to the database? I assume you have different database/settings/cache/etc files for each branch, to avoid cross-contamination, and using a merged directory requires lots of temporary "commit; switch; uncommit; commit; switch; uncommit" cycles (which take bloody ages). In Bazaar, I just "cd ../otherbranch".

As for Python paths, if you can't figure out how to use relative paths, maybe the problem is you.

quote:

http://code.google.com/p/msysgit/

That's like saying I can run SourceSafe natively in Linux, because it works in Wine. I don't want to install GCC/Bash/etc just for a source-control system.

bitprophet posted:

Right, my point is that I think you're working off of old info. I just made a random binary file with dd and then 1) added it as-is, 2) renamed it without modifying it, and 3) renamed AND modified it in the same commit.

[...]

I just tried it with git 1.6.2.3 (latest for download), and it didn't work correctly:

code:

$ dd if=/dev/urandom of=test.bin bs=1024 count=1024
$ git add test.bin
$ git commit -a -m "Created"
$ dd if=/dev/urandom of=test.bin bs=1024 count=1024
$ git commit -a -m "Modified"
$ git mv test.bin test2.bin
$ dd if=/dev/urandom of=test2.bin bs=1024 count=1024
$ git commit -a -m "Moved and modified"
$ git log --follow test2.bin
commit 100444da...
Author: User <user@vm.local>
Date: Fri Apr 17...

    Moved and modified

e: tried again with "git mv", same result

TOO SCSI FOR MY CAT fucked around with this message at 17:58 on Apr 17, 2009

# ¿ Apr 17, 2009 17:52

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"

deimos posted:

I don't think you "get" msysgit.

Git's written in C, shell scripts, and Perl. Unless msysgit is a rewrite of all the scripts into C, it will require a UNIX shell, supporting binaries, and Perl to be installed.

king_kilr posted:

SQLite is just a file and it's managed in a different repo from my actual work on Django itself.

And the rest of the file types I mentioned? Not every project is so self-contained that there are no cache or temporary files generated.

king_kilr posted:

What? I keep django in /home/user/django_src/ what would you like me to set my python path to such that everything would Just Work(tm) if I were to move it to be in a different directory?

If you've got a project you're devloping in ~/django_src/, then instead of hardcoding "/home/user/django_src" into testing scripts, just add the project's current directory to the Python path.

# ¿ Apr 18, 2009 00:53

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"

king_kilr posted:

I don't understand this? Delete your temp files, keep them in the repo, or use git stash. You seem to be arguing that people have files that need to exist in the same directory as the repository, need to be long lived, and aren't actually part of the repository.

That's precisely what I'm arguing, because that's something I've experienced both with my own projects, and others.

king_kilr posted:

I don't hardcode anything to my other scripts, they simply import django. I have ~/django_src/ on my python path, however if that's a moving target I have to be constantly moving my pythonpath, you seem to be acting deliberately obtuse.

So you've got several scripts that are hardcoded to use a particular directory, which may or may not actually be the version they expect to import? Awesome.

# ¿ Apr 18, 2009 01:51

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"

Pardot posted:

Maybe I also don't get it, but isn't that what .gitignore files are all about?

I've got a branch. To work on that branch, I need a large temporary file that takes time to generate. If I switch to another branch, I have two choices:

* Leave the file in place, and risk corruption from two different versions of the code modifying it.
* Delete and re-generate the file each time I change the branch.

# ¿ Apr 18, 2009 15:27

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"

sklnd posted:

I really don't see how that is different from a sqlite db (aside from the corruption bit). Seems like you should just move your temp file out of your repo (say, into a tmp directory where it should be anyway?) and have a config setting telling your code where it is. Anything else seems to be a bit insane anyway if you're going to be jumping between such disparate branches often.

Or I could just not restructure my project to work around deficiencies in the version control.

# ¿ Apr 18, 2009 17:06

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

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

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"

nbv4 posted:

Whats the best source control program for single person projects? Right now I have a website project that I manage with SVN. Basically I just use it to streamline moving files from my local machine to my webserver. Instead of manually moving files with a ftp program, I just commit, then ssh into my server, then checkout.

Its gotten to the point where I think I need to start branching. I want to add new features, but don't want to tie up my source in case a bug is discovered in myworking site while the SVN repo is tied up in my developement of a new feature. I head SVN is bad at branching. Should I switch to another program like git or w/e or will SVN be fine?

Bazaar (my preference) or Mercurial are both good choices.

# ¿ Aug 7, 2009 06:07

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"

Profane Obituary! posted:

Hey guys i want to be able to branch, does svn do this?

MAN YOU SHOULD TOTALLY SWITCH TO MY FAVORITE VCS

If all he needs to do is branch, and doesn't care about merging, just copying the directory will work as well as using SVN.

# ¿ Aug 7, 2009 18:18

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"

floWenoL posted:

Honestly, any distributed VCS will do just fine in place of git (I don't remember which one is the Windows-friendly one).

Any of them which aren't git are very windows-friendly.

# ¿ Aug 7, 2009 21:38

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"

rotor posted:

Sadly, I'm not enough of an idiot to say that svn can do everything git can, since that would be obviously factually incorrect. My issue is that I don't think this guy needs to go to the trouble of moving his vcs midproject because I'd guess that the ROI on the effort investment will basically never pay off. I think git advocates tend to overstate the both benefits of their VCS and the deficiencies of svn.

If he was starting a new project I'd say yeah, go nuts, git is probably a better choice. But he's not.

There's very little effort involved in switching from SVN to another VCS. Just install the new VCS, fast-import the repository, and archive the SVN version somewhere.

# ¿ Aug 7, 2009 22:11

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"

rotor posted:

right, and then you have the actual work of learning how the new vcs works and how to take advantage of all these miraculous new features.

svn commit -> bzr commit
svn update -> bzr pull
svn cp trunk/ branches/fix-poo poo -> bzr branch trunk fix-poo poo
?????? -> cd trunk; bzr merge ../fix-poo poo

# ¿ Aug 7, 2009 22: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"

stray posted:

I'm learning to program ObjC/Cocoa and I still do some web design, though mostly for myself. Even though I'm working alone, I want to put all of it under version control (not only for peace of mind, but because it's just a good habit to get into). In the past, I usually just used snapshots of folders and burned discs.

So here are my questions:
1) I have Subversion on my MacBook Pro and I'm looking at Versions.app (a front-end to SVN), but it seems like the one developers really seem to love these days is Git. Should I use Git or is SVN fine?
2) Since I'm going to be doing web development, too, how do VC stystems handle images? Will SVN/Git hold full copies of images/PSDs, or will it just store the deltas (which would screw up binary files like JPGs, PNGs or PSDs)? What are people's thoughts on images in version control systems?

I would choose a distributed VCS, rather than Subversion -- my favorite is Bazaar. However, any of the "big 4" (Bazaar, Darcs, Git, Mercurial) should work fine for you.

Some VCSs store binary files in full, others use deltas. Deltas won't "screw up" files, but whether they save space will depend on the formats you're storing. For example, PNG or JPEG files will usually not see much advantage from deltas. I don't know enough about PSD to comment on it.

# ¿ Jan 25, 2010 23:11

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"

Sizzlechest posted:

No. It's a matter of whether or not you intend on implementing a distributed vcs as a distributed vcs. People keep crowing about how centralized vcs is obsolete, when that's exactly what they end up doing.

I keep re-reading this paragraph, but no matter how hard I try, it never makes any sense.

SVN doesn't support branching. I can't branch from the main repository to my workstation, make commits locally, and then merge them back. This is why SVN, or any centralized VCS, are awful to use.

Bazaar/Mercurial/Darcs/Git do support branching. I can branch from the main repository to my workstation, make commits locally, and then merge them back. This is the entire purpose to distributed VCS.

# ¿ Mar 12, 2010 03:34

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"

MachinTrucChose posted:

I know this isn't the right thread, but anyone recommend a version control tool that works well (fast) with binary files, and is simple to use by a non-technical Windows user?

This is totally the right thread.

All major DVCS (bazaar, mercurial, git) are basically the same when it comes to binary files; they might have some basic compression or bdiff logic, but there's no way around the fact that you're versioning 500MB blobs. They do have all your requested features, and should be reasonably fast, but the repositories will be huge.

Since installing and testing them should take maybe 5 minutes max, how about you just try them out with his workflow and see which works best? Bazaar has a Windows shell extension built in, Mercurial has TortoiseHg, Git has TortoiseGit

# ¿ Nov 22, 2010 18:57

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"

danishcake posted:

Can anyone recommend an issue tracker that can be used in a distributed fashion? Ideally I want something with minimal dependencies along the lines of TiddlyWiki, but tailored to issue tracking, and able to cope with a little light merging. Installing Python etc is not an option, but I do at least have access to a modern browser.

How about a todos/ directory? Create one file per error/feature/problem, edit it as normal, move it to todos/finished/ when it's fixed on your branch. Merges should be pretty easy.

If you want something a little more heavyweight you can use Fossil, assuming you're allowed to install it.

# ¿ Dec 22, 2010 18:36

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"

Mithaldu posted:

Sadly not: http://whygitisbetterthanx.com/

HG is missing two of the most important features: On-the-fly branch switching (it literally takes less than a tenth of a second to switch a branch in git and only takes a right-click followed by a single click in the context menu) as well as the staging area.

This page is pretty much entirely incorrect regarding competing DVCS. It's cute; but when you see numbers like "git: 1.6s, bzr: 82s", it's obvious that the author is doing something wrong.

For example, you can't compare "clone" operations by timing how long it takes to download from four completely separate websites, and saying that git's "branch" is faster than bzr's is useless when they are actually entirely different commands that happen to have the same name.

In the last point, he says Git is better than Mercurial because of Github, which makes me think the page is *really* old (Bitbucket was launched in 2008). He also doesn't mention what versions he tested with, which makes a big difference (especially on the performance-related parts).

Finally, I think it's *really* weird that he lists "cheap branching" as the first one, *and* claims Mercurial and Bazaar don't support it. Bazaar has supported cheap branches since 0.8 (released: 2006), and if I remember correctly Mercurial had them even earlier.

Captain Corny posted:

VCSes are meant to be used from the command-line. Graphical wrappers are just hobbles used by idiot "I took an Excel class in college!" types who are too frightened of real software to get any work done.

If you're dumb/crazy enough to use Windows as a development workstation, you do not have permission to complain when standard tools do not work properly any more than someone still using Netscape 4 gets to complain about Google Docs requiring Javascript. Spend half an hour and install a real OS.

It's obvious from your posts that you expect your VCS to hold your hand, spoon-feed you, and change your diaper before each commit. Maybe you'd be happier with Visual Source Safe -- it's got "visual" right in the name!

# ¿ Apr 21, 2011 05: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"

Captain Corny posted:

Nice attitude. Try reading what I'm actually saying next time.

You mean these posts? Here, I'll reply to them line-by-line to emulate your terrible posting:

Captain Corny posted:

Right, but I didn't really have any choice. It just saddens me that Git apparently was designed for Linux only, and that any use for it on other (much bigger) platforms was ignored because of some misplaced and immature pro-Linux bravado. It's just a dumb strategy to follow and even for that reason alone I don't like Git.

Linux *is* the "much bigger" platform, for developers. Git's not a My Little Pony video game, it's a developer tool, and if you don't want to use it on a developer OS then that's not Git's fault. You might as well complain that Photoshop is hard to use because it doesn't run well in FreeBSD.

Captain Corny posted:

Whoever was developing it were wasting their time because they apparently collectively decided to make it Linux only with extremely limited support for other platforms. How's that?

The developer of Git is the developer of Linux. Git was written for the single purpose of managing the Linux kernel. There is no reason for it to be ported to any other OS.

Captain Corny posted:

So, an early software design decision ends up exposing first time Git users to the complex inner workings of the software they're about to use. Bad design decision. Dumb design decision.

e2: Perl, really? What's Perl doing in what ought to be a straight C/C++ project.

Yes, an early design decision to run on the OS it's used to develop dooms Git to working well on...the OS it's used to develop, and that everyone who wants Git already uses.

First-time users aren't exposed to any "complex inner workings" unless they're installing on a broken OS that doesn't come with any standard developer tools, like Bash or Perl.

Captain Corny posted:

Full-blood Linux coders.

"Full-blood coders" == "Full-blood Linux coders"

Captain Corny posted:

I get that. The design decision I talked about was made by the core developers, not the msysgit developers. Still a bad decision.

Just because it happens to frustrate your bizarre, obscure edge case (running a complex UNIX tool on a non-POSIX OS) doesn't make it a bad decision.

Captain Corny posted:

While coders are the main beneficiaries of version control systems, the popular versioning tools of the future are going to be used by a lot more people than just coders.

No they're not.

90% of VCS features are targeted to and intended for programmers. There's no reason for non-coders to ever care about branches, or merging; in fact, the typical non-code file (graphic images) can't be reasonably merged at all.

If you want non-developers to use VCS, write them a few simple tools with two or three buttons ("find changes", "send changes", "mark change") and don't expose them to branches or repositories or any of that.

Captain Corny posted:

I am familiar with the principle, but this sounds like an example of adhering to a principle to the point of crippling yourself, and therefore a bad decision. Someone in this thread pointed out that libgit, through necessity, is now being rewritten to make it at least bearable to use on other platforms. Talk about repeating yourself.

It's hardly crippling, if the only people it impacts are the set of programmers who can't figure out how to install Perl (a set which, until I recently, I would have assumed null).

Captain Corny posted:

That may be true for small scripts and tools, but once you decide to go into anything heavier (and 4+ months development time for just a tool is heavy), and when you are creating something that's intended for external use, and when you are creating something that's intended to be a replacement for another tool that is available on all platforms, it's generally a good idea to look at who your userbase is going to be. And particularly with version control, you should design your software to be at least portable enough that somebody else can make a version for another platform. There seems to be a fundamental difference of opinion on this between us.

Linus didn't write Git to be a general-purpose VCS. It was explicitly a replacement for Bitkeeper, it only needed to run on Linux, and any amount of platform-dependence was acceptable in the name of performance.

The predicted (and, so far, major) userbase is Linux kernel developers. Some guy who used Git for his 200-line Rails plugin because he saw a cool screencast about it doesn't matter.

Captain Corny posted:

Of course, they are free to make their tool as they see fit and be happy about it. Not giving a gently caress is a right that I'll be the first to defend, and designing a good UI is a lot more work than inflicting unnecessary pain on your users. However, don't be surprised when people don't want to use your creation as a result of that.

The Git target audience doesn't seem to mind its UI at all.

Captain Corny posted:

Not at all, it's an entirely different thing. With cross platform development, you make your application cross-platform (or at least easily portable) from the first line of code you write. It's what I mean with early design decisions. Git was clearly not developed to be cross platform (bad early design decision IMO), so it's no surprise that people are running into problems getting it ported. CVS and SVN had decent Windows support from the start. They were cross platform and CVS existed before Git even started development, which proves that even back then, it was not impossible to develop cross platform.

Again, you assume that being cross-platform is important to a developer tool. That's simply not true; off the top of my head, I can't think of a *single* major developer tool that works well on anything but the platform it was written for.

Visual Studio: Windows only
XCode: MacOS only
Emacs/Vim: POSIX only
Git/Mercurial/Bazaar: POSIX only (the Windows ports are jokes)
SVN/CVS: POSIX only (the Windows ports are missing major functionality)
Autotools: POSIX only
(... a bunch more marked "POSIX only")

If you want to insist that CVS was cross-platform, then you don't get to say that Git isn't -- Git works at least as well, if not better, on Windows than CVS ever did.

Captain Corny posted:

I'm sorry, but this is bullshit. There's always a lead developer, or some kind of body that makes decisions about architecture or design, even in open source. This doesn't even have to be formal. It just always works that way.

No doubt this highly informed and reasonable paragraph is based on your years of time in the Linux developer community?

Captain Corny posted:

But even if that wasn't true, what you're basically doing is making excuses. "Sure, the software has flaws but it's because of the build process." "Sure, the installer is harder to use than it should be, but that's because it depends on a set of tools that aren't available on Windows."

The only thing that matters to the end user is what the software does, not how or why it came to doing that.

Or how about : it's a tool for developers, by developers, written for the premier development platform, and it's been ported to Windows by a handful of volunteers who don't care if the installer needs to ask the user a few questions because it'll only ever have a market share of 100 users on that platform.

Captain Corny posted:

It doesn't unravel squat. It is entirely irrelevant what it was intended for. The only thing that matters is that it *did* get released for Windows. That fact alone makes it completely fair to compare it to other Windows applications and to pass judgment on it from a Windows centric perspective.

No it doesn't, and you're an idiot for claiming it does. If I somehow manage (through emulation and trickery) to get a MacOS application running on Windows, it would be idiotic to claim it's a badly-designed application because installation was difficult and the UI doesn't look right.

Captain Corny posted:

You're completely misrepresenting my point now. The installer doesn't ask you to think, it asks you to *know*. Not only that, it asks you to know things that you can only know when you're already a user of the software. And that's unreasonable.

Or, you could just click through and select the (well-chosen, reasonable) default options.

Captain Corny posted:

Seriously? You don't have something better to be appalled about than what some guy writes on the internet about a piece of software you're using? And you think the rest of the thread is with you on this? In that case, let me hereby apologize for offending your delicate sensitivities. I didn't realize how emotionally attached you were to Git.

I'm more appalled by your terrible posting.

Captain Corny posted:

You keep saying that Git's Windows support is awesome, yet the Python devs recently chose Mercurial over Git. One of the key reasons was lack of decent Windows support.
http://www.python.org/dev/peps/pep-0374/

The Python developers chose Mercurial because it's Guido's favorite. The poll was only ever a formality; they decided on Mercurial from the outset, and then looked for reasons to reject the other VCS contenders.

That's not necessarily a bad thing -- Mercurial is a pretty good choice, and there's no compelling reason to pick any one of the major three DVCS in existance -- but you don't get to use it to support your position. Git on Windows works as well as Mercurial does, certainly.

Captain Corny posted:

I don't see how that's incredible. Decent Windows support is a pretty basic and common requirement for software that's supposed to run on Windows.

What about for software that's not supposed to run on Windows, and doesn't have any significant Windows user base, and is designed for users that are actively writing an alternative operating system?

# ¿ Apr 21, 2011 16:41

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"

epswing posted:

Actually Mercurial works super nice on Windows. I don't have enough experience with the other two VCS systems you mentioned to comment on their level of jokeness on Windows.

_{(I agree with the majority of your other points)}

The last time I used Mercurial on Windows, it couldn't handle:

* symlinks
* hardlinks
* files named "makefile" and "Makefile" in the same directory

Has support for these improved/been added? I don't use Mercurial day-to-day.

# ¿ Apr 21, 2011 17:38

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"

wellwhoopdedooo posted:

VIM is one of the first things I install on every Windows system that's mine. Well before I install Cygwin.

What functionality is TortiseSVN missing?

Sure, but you've got to admit it's a very non-native experience, right? I have 7.2 installed on a Windows machine somewhere, and it uses different fonts, graphical widgets, and even a separate clipboard.

TortoiseSVN is a wrapper around SVN; SVN itself is, like Mercurial, reacts poorly when the repository contains links or case-differentiated filenames. It's not really the SVN developer's fault, it's just that the platform is missing features that the tool allows.

# ¿ Apr 21, 2011 17:47

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"

wellwhoopdedooo posted:

It's a pretty big leap to call something "POSIX Only" because CTRL-C doesn't copy.

e: It does use the same clipboard, the copy command is just mapped differently. Use copy from the menu.

In the version of Vim I used (7.2 from vim.org), the vim clipboard (yy/dd/p and friends) and Windows clipboard were separate -- eg, you could copy "foo" in vim, copy "bar" in notepad, and then paste "foo" in vim. It's quite possible that this behavior was due to a problem with my machine.

"POSIX only" was a poor choice of words, I should have chosen something like "POSIX native" instead. Basically, I wanted to convey the feeling of "this was obviously written for a different OS" that comes from features like :! working sorta-but-not-quite.

# ¿ Apr 21, 2011 18:01

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"

Mithaldu posted:

I think you might be misreading things.

[...]

Note the 0:40.42elapsed. During this time no network traffic happened. Did i do something wrong too?

Yes -- if you want to compare branching in a local Git repo, you should compare it to branching in a local Bazaar repo:

code:

$ bzr init-repo dj
$ cd dj
$ time bzr branch lp:django dj-bzr
$ time bzr branch dj-bzr dj-bzr2

The second branch should be much faster than the first, because it's creating a local branch instead of a separate repository.

Mithaldu posted:

Bazaar: I wouldn't call 40 seconds cheap. Neither is it particularly cheap to switch branches if "to branch" means "create a new directory". (And i haven't even looked into rebase (or similar) capability.) As such, i think it is entirely fair to say Bazaar has no such thing as cheap branches. If you still think so, please show us how i can create a branch or branch-like thing in Bazaar in under a second and also switch to another one while staying in the same directory.

See above for how to use local/cheap branches.

The typical workflow of Bazaar is to have one branch per directory; however, you can use "bzr switch" to change what branch the current working copy uses. I like per-branch directories, so I don't use it much.

Mithaldu posted:

Mercurial: I have to admit, as far as speed and ease for creating and switching go, its on par with git. So his benchmark there seems to be completely out of date now. On the other hand, i still have to deduct points for lack of rebasing. That's pretty important to have.

I think Mercurial has a plugin for rebasing -- Bazaar has for a while, and it's a pretty popular feature.

# ¿ Apr 21, 2011 21:46

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"

Captain Corny posted:

Maybe I created 'Janin' to let the rest of the thread see how dumb a typical Git user is.

I don't even use Git; my most used VCSes are Perforce (at work), Bazaar (at home), Mercurial (when using BitBucket-based projects), and Darcs (my old at-home VCS, still migrating stuff from it).

You're just too dumb to realise how dumb you are.

# ¿ Apr 21, 2011 21:49

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"

Thermopyle posted:

So, I've got a little-ish app that I'm developing. When I do a release version, I tag that commit (using git, BTW) with the version number, then I go on happily developing.

When I need to do a bugfix on that version (like if I'm not far enough along in development to do a release of a newer version), I create a bugfix branch from that tag and then release from that branch.

This is awkward because if I merge that branch back in to my development branch to get those bugfixes back in it can be a big mess because I may have done large structural changes or whatever.

What's a better way to handle this?

You're already doing it properly; there's not any perfect ways to merge bugfixes from one branch into a very different branch.

# ¿ Apr 25, 2011 22:14

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"

devilmouse posted:

My VCS experience has all been in Perforce and the current company is slowly migrating to Mercurial. I'm embracing it as best I can, but there's one nagging thing that I can't find a replacement / equivalent of in the new system... In Perforce, I'd have many changelists that I'd be working in at a time (let's ignore WHY I'm doing this for now). The closest I can find in Mercurial is the Shelve extension. Is this what I'm looking for or should I me making a bunch of branches to simulate the changelist behavior?

The "traditional" answer is to maintain a separate local branch (roughly equivalent to a p4 client) for each change. This keeps them isolated and prevents accidental dependencies between CLs. I think Mercurial supports hardlinks, so disk usage should be somewhat reasonable.

You could try using mercurial queues; I haven't used them before, but a quick scan of the docs shows they might do what you want.

If your CLs have dependencies between them -- eg, you're splitting up a huge change into 3-4 CLs -- then you will probably just have to use 'hg st' and commit them separately. Depending on how awful this is, you could try writing a simple plugin that lets you tag open files and commit only files with a certain tag.

# ¿ May 2, 2011 17:49

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"

devilmouse posted:

I might just bite the bullet and write a quick bunch of scripts to deal with this on my own, but it seems like I'm being contrarian to what hg wants me to be doing anyway and not learning The True Way.

Chill out. There is no such thing as a "true way", in any programming discipline. There *are* collections of "best practices" that work in the general case, but feel free to discard or modify any of them if needed.

In Mercurial, as in most DVCS, the best practice is to have one branch per logical change. This works well for most users. If it doesn't work for you, just find a different solution. Nobody will judge you.

# ¿ May 2, 2011 19:09

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"

Adahn the nameless posted:

Why is that the case? I'm using Mercurial because it's easy and Joel Spolsky wrote a really good tutorial for it, but sometimes it seems that every open source project of worth is on Git. Why is that? What does it have over Mercurial?

It's used for Rails, which therefore makes it automatically better than every other VCS, usability and features be damned.

# ¿ Aug 17, 2011 03:52

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"

DreadCthulhu posted:

So, has anybody here tried both bzr and git and made up his mind about what's better? I'm a git user myself, and have heard good things about bcz. Given that I'm a total whore and have no allegiance to any specific tool, I'll gladly switch over to bzr if the feature set is obviously better.

I think the prob is that there's nothing equivalent to GitHub right now, so it's almost unavoidable to stick to git because of it. It's becoming a standard.

I use Bazaar for pretty much everything; it's nice because it's in Python, so there's a real API instead of just bashing everything together with thousands of lines of shell scripts. This advantage also applies to Mercurial.

Oh, and the UI is designed rather than accreted.

It can push/pull to pretty much any other VCS (cvs/darcs/git/hg/svn), so you can use it even for people who use GitHub or Bitbucket or whatever.

# ¿ Aug 19, 2011 06:58

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"

Mithaldu posted:

Yeah, but what if i exploit your image thumbnailer to permit me read access to arbitrary paths on your system? (Just as an example.)

So what?

If you can read arbitrary paths, you can already access the source code. There's nothing extra to read from having read-only access to the repository.

# ¿ Sep 8, 2011 01:18

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 07:09

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"

Mithaldu posted:

You don't have much practical experience with system intrusion, do you?

It gives me the urls of your source repo, which may be accessible on the internet, or at least proxied throught he server; as well as the login credentials, which may be read-only, but provide strong hints on how to brute-force the write creds; in either case, having read credentials at least gives me the whole history of the repo, as well as any other projects stored in there; and with git i don't even need any credentials because the history is right there; and who knows what nice extras like hastily reverted passwords the history contains...

So you're saying that somebody prone to gross stupidity might be doing tons of other stupid things. That makes sense, I guess. But there's nothing related to source checkouts in that argument. It's like saying you should obfuscate all the source code before copying it over, because a developer might have posted their credit card and DOB in the file header.

There's no reason to expose a source repo on the internet. There's no reason to let the webserver have any sort of credentials (just git/bzr/hg push to it). There's no reason why passwords should be stored in the history (they should be changed immediately, and the relevant history expunged).

Mithaldu posted:

Try thinking about what someone with determination AND creativity could do.

You're acting as if a source checkout is a horribly dangerous thing to have, when in reality it's right next to "broadcasting an IP address !!!" in terms of risk to your servers.

Mithaldu posted:

Leaving the security impact aside there's also the fact that a source checkout is not an atomic operation, the changes of it happen as git/svn/whatever touches the files, which, combined with ongoing user access can lead to interesting situations.

That depends on your VCS, and how you manage versions. Check out the new version, then set your webapp's live path to the checkout. Boom, atomic.

# ¿ Sep 8, 2011 04:00

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