|
This thread is locked; no one can reply to it. |
1
2
|
Wednesday Moan: I've decided SVN sucks |
Neil Walker
Member #210
April 2000
|
Here I am migrating some stuff from one system (StarTeam) to another. So after conversion (it creates a dump file) I load the dump file. I then purge unnecessary files and move files around. Then I create a dump of that. I know I can use svndumpfilter (but it's crap), but there is no permanent deletion option (so all the files that shouldn't be there are lying around consuming space and wasting time in loading). When I watch the process of 'svnadmin load' you can see why it's painfully slow - it creates your repository as it was then applies all the changes afterwards (like my moving of folders/files and deletion of files). I like SVN, but svn load/dump and purging is dreadful. Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
Thomas Fjellstrom
Member #476
June 2000
|
I assume it wouldn't be that hard to parse the dump file and just delete crap you're not interested in. -- |
gnolam
Member #2,030
March 2002
|
Thomas Fjellstrom said: I assume it wouldn't be that hard to parse the dump file and just delete crap you're not interested in. Which is pretty much what svndumpfilter does. -- |
bamccaig
Member #7,536
July 2006
|
Subversion does suck, though I think this is the least of its problems. If you can, I suggest migrating to Mercurial or Git. At the very least, acquaint yourself with them so that you can recommend them to your company. ** EDIT ** Neat. Git actually has the ability to do this relatively easily: http://help.github.com/removing-sensitive-data/ I'll be trying it out in a minute so I'll let you know how efficient it is. ** EDIT ** I actually had to edit a password out of a file so I couldn't just delete it, but Git did it just fine. My project is quite small so it was fast, but I'm guessing it would be quite slow on a large repository (understandably). Apparently you can speed it up by specifying tmpfs as the device to work on. Anyway, my command line was basically this: git filter-branch --tree-filter \ 'find -name SourceFile.java -execdir \ sed -i s/sensitive\ string/placeholder\ string/' master git log -Ssensitive\ string [Should be no output if it worked happily] [Make sure the repository looks happy] git push --force origin master Unfortunately, apparently the sensitive information still exists in the repository, but we've basically hidden it. If somebody has the SHA1 hash for the now hidden branch then I think they can still recover the data. You'd have to create a whole new repository to completely get rid of it. This is fortunately pretty easy since you already have a complete clone of the repository (though I'm not sure whether or not pushing into the new repository will again push that sensitive information). I used this to fix a project on GitHub that had a relatively worthless password in the source code, but a password nonetheless: Note line 40. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
BAF
Member #2,981
December 2002
|
Your quit function is overly verbose and unnecessary. You can just quit with your quit message. |
bamccaig
Member #7,536
July 2006
|
BAF said: Your quit function is overly verbose and unnecessary. You can just quit with your quit message. It doesn't seem to actually work anyway. At least, when I've tried it in the past it would just quit without giving a reason. If you're referring to parting from each channel before quitting then I suspect you are correct. I was more or less experimenting when I wrote the existing code. I haven't actually begun writing anything remotely useful yet. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
BAF
Member #2,981
December 2002
|
Yeah, I've noticed that the quit message randomly doesn't go through on Freenode. Try testing on a network that doesn't use buggy IRC servers. Anyway, it doesn't really matter if the quit message goes through or not IMO, especially if you're writing a bot. |
Steve Terry
Member #1,989
March 2002
|
We use CVS at the j0rb and I think it's pretty useful. I've had to make branches of projects before and merge them up after making drastic changes with little problems (.NET). I have to say though that checking out and committing changes is a little slow, but I'm getting paid for it so why complain . ___________________________________ |
bamccaig
Member #7,536
July 2006
|
You just have to try out Subversion and you'll quickly see that CVS doesn't work very well. Then try out Mercurial or Git and you'll quickly see that Subversion doesn't work very well either. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Billybob
Member #3,136
January 2003
|
bamccaig said: Then try out Mercurial or Git and you'll quickly see that Subversion doesn't work very well either. Git didn't have a good GUI when I tried it (a year ago). TortoiseSVN is amazing
|
bamccaig
Member #7,536
July 2006
|
There is a TortoiseGit now, but I think it's still somewhat immature and installing it isn't as simple as with the other TortoiseSCMs (you have to manually install msysgit first, which in itself isn't completely non-trivial). That's only relevant to Windows though. Linux and presumably other unices have had gitk for a long time, I think. Not that it matters. The GUI wrappers all suck compared to the command line interface. GUIs are fundamentally flawed when it comes to non-graphical work because they require 10x longer to design and develop and 50x more work to use for non-trivial things (and they don't interface with one another easily). GUIs are nice for graphical data, like a branching graph, for example, or graphic design. Get used to using the command line. Even in Windows it's a lot faster and cleaner for 99.99999% of things (especially when you install Cygwin or MSYS to supplement it). -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Thomas Fjellstrom
Member #476
June 2000
|
I think KDE has a git plugin now. So you can see git status from Dolphin, the file dialogs, or konqueror. -- |
Kibiz0r
Member #6,203
September 2005
|
bamccaig said: The GUI wrappers all suck compared to the command line interface. ...which also sucks. Git is an excellent system, but goddamn can you tell it was written by coders for coders. I don't know why you'd decide to improve the mechanical side of version control without even keeping the same level of usability. Also, for my OS X brethren, GitX is an okay GUI for Git. I still use the command line most of the time though. --- |
Matthew Leverton
Supreme Loser
January 1999
|
I use git. |
Billybob
Member #3,136
January 2003
|
bamccaig said: There is a TortoiseGit now I tried it a year ago, and it was too buggy to use. Quote: The GUI wrappers all suck compared to the command line interface. Exactly, that's the problem. Quote: GUIs are fundamentally flawed when it comes to non-graphical work I value having a GUI interface to whatever SCM I use. Therefore, Git, from my point of view, sucks, because it doesn't have a good GUI. This isn't about what is the most effective way to use a tool; I am simply more comfortable using a GUI. Also, updating a Git repo from one machine to the rest of my machines was too difficult. I tried out Git over a year ago, so my memory is vague, but I remember spending a few hours trying to set up every machine just right, and still couldn't get it to work fluidly. I eventually just gave up and setup a project on Github, but then that kind of defeated one of the key features I liked about Git (being server-less).
|
Elias
Member #358
May 2000
|
bamccaig said: You just have to try out Subversion and you'll quickly see that CVS doesn't work very well. Then try out Mercurial or Git and you'll quickly see that Subversion doesn't work very well either. But if you ever get to try out Perforce, you will realize that even CVS is great. -- |
Neil Walker
Member #210
April 2000
|
I tried perforce a while ago and it was ok, but after using tortoiseSVN I prefer the non-thick client approach, either the explorer plugin like tortoise or direct IDE integration. I don't see why I should have to use another program just to manage files. Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
bamccaig
Member #7,536
July 2006
|
Billybob said: Also, updating a Git repo from one machine to the rest of my machines was too difficult. Actually it's incredibly easy from Linux to Linux. You probably won't even need to worry about setting up daemons because Git can work directly over SSH. For example, if you have a repository at /home/user1/src/project1 then you could use the URI user1@host1:src/project1. git remote add my_remote user1@host1:src/project1 git push my_remote master And just like that, it will be updated with changes to branch master from your local copy of that repository. When you clone, you typically get a remote named origin already set up for you that points to the cloned repository. It seems getting a daemon running with the git protocol is a little bit more work. There is git-daemon for this, but it doesn't support authentication so you'll probably only want to use it read-only (the default). I haven't quite figured out the daemon aspect of Git yet. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Billybob
Member #3,136
January 2003
|
bamccaig said: Actually it's incredibly easy from Linux to Linux. Which is awesome. SSH in Linux seems to come in handy on countless occasions. However, some of my machines run Windows. To be clear, I want to use Git. From what I have read about it, it has features I would enjoy. I just seems to have its head up its butt and refuses to support anything other than Linux with a CLI. So, here I am, stuck with SVN.
|
bamccaig
Member #7,536
July 2006
|
Billybob said: I[t] just seems to have its head up its butt and refuses to support anything other than Linux with a CLI. So, here I am, stuck with SVN. Unfortunately, you're just wrong. Repositories can be published via HTTP, FTP, rsync, or a Git protocol over either a plain socket or ssh. Git also has a CVS server emulation, which enables the use of existing CVS clients and IDE plugins to access Git repositories. Subversion and svk repositories can be used directly with git-svn. Basically, Git supports way more protocols than Subversion does. It was developed by UNIX programmers for UNIX programmers. I really don't think Linus Torvalds could care less about Windows (for good reason). In the beginning, the only way one could use Git (and therefore begin to care about it) was if they were a UNIX-like user. Since some of us have to work with Windows anyway (some of Honestly, if the code you're working on is intended to be released as open source then you're best off just using a free service, like GitHub. If proprietary, you always have the option to pay one of those services to host a private repository for you too. Or you can just run a Linux box somewhere and get a "central" repository working on it to use as a go-between. If you try hard enough, you can probably just get a service running in Windows to work as well. It seems you can use Apache and WebDAV if you're inclined to do so. With a bit of bastardization, you could even host a Subversion repository and then use git-svn to communicate with it (though I wouldn't call that a full-fledged Git experience). -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Tobias Dammers
Member #2,604
August 2002
|
Billybob said: I just seems to have its head up its butt and refuses to support anything other than Linux with a CLI. So, here I am, stuck with SVN. There's always mercurial; it's slightly less feature-laden than git, and maybe (although I haven't noticed yet) a bit slower, but while git is an amalgamation of C programs and shell scripts, and thus harder to port to non-unix-like platforms, mercurial is written in python, and the windows version is pretty much on par with the various *nix ones. There's a really nice painless introduction written by the Joel from joelonsoftware, which should help avoid a lot of confusion, especially for those coming from a central-repo SCM system. Neil Walker said: but after using tortoiseSVN I prefer the non-thick client approach, either the explorer plugin like tortoise or direct IDE integration. I don't see why I should have to use another program just to manage files. A CLI program is about as thin as it gets. An explorer extension is in fact just another program (or a whole bunch of them), and so is an IDE plugin; you just access them from within another program. Most IDE plugins I have worked with are even worse than Tortoise{insert SCM}. There's another reason people like CLI interfaces: They're scriptable. A distributed SCM also gives you a sophisticated incremental backup mechanism: Just write a little script that pushes all your local repositories to a backup location, put it in a cronjob, and that's it. Oh, and before bashing any SCM, just try to remember what it's like when you have to work without one. You don't want to go there - everyone working on the same network share? bi-hourly zipped backups? keep track of versions in Excel? mailing around individual source files and puzzling them together in nerve-wrecking all-nighters? No thank you. I'd even take CVS over that. --- |
bamccaig
Member #7,536
July 2006
|
Tobias Dammers said: You don't want to go there - everyone working on the same network share? bi-hourly zipped backups? keep track of versions in Excel? mailing around individual source files and puzzling them together in nerve-wrecking all-nighters? No thank you. I'd even take CVS over that. I have it on good authority[1] that tarballs and patches are actually more sophisticated than CVS. They certainly sound more friendly to me. Now, if it was a choice between working on the same network share, tracking changes with Excel, or using CVS then I would probably give in and use CVS... References
-- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Trent Gamblin
Member #261
April 2000
|
You could probably write a VCS in Excel though. People have wasted countless hours writing all kinds of crap with that thing.
|
BAF
Member #2,981
December 2002
|
Aww, how cute. Little bam bam wants to be just like linus when he grows up. He even believes that tarballs and patches are better than CVS. |
Arthur Kalliokoski
Second in Command
February 2005
|
BAF said: Aww, how cute. Little bam bam wants to be just like linus when he grows up. He even believes that tarballs and patches are better than CVS. You use Visual SourceSafe, I suppose? [EDIT] I found this googling: "SourceSafe was a perfectly adequate source control system in the late 90's. Unfortunately, SourceSafe was never updated architecturally to reflect modern source control practices. Even the latest version, SourceSafe 2005, absolutely reeks of 1999. And, to be fair, some of the same criticisms apply to CVS. CVS is no longer a modern source control system, either; it doesn't even support the concept of atomic checkins" http://www.codinghorror.com/blog/2006/08/source-control-anything-but-sourcesafe.html They all watch too much MSNBC... they get ideas. |
|
1
2
|