|
sonic bed head posted:I used "svn delete." The files are definitely not in the head revision of the trunk. Also, the merge command is exactly skipping the ones that have been deleted, so it must know that the deletions have happened. I don't know about your particular issue, or the current state of SVN, but historically SVN hasn't handled merging updates to the trunk into branches and then back to the trunk very well. An alternative is to create a new branch from the trunk, and merge your changes from the original branch into the new branch.
|
#
¿
Apr 11, 2009 00:31
|
|
|
|
| # ¿ Apr 28, 2024 12:30 |
|
|
Lysidas posted:This isn't true anymore. msysgit is very stable and I enjoy using it on Windows. I was a diehard TortoiseSVN/SmartSVN user and never touched the SVN command line, but there are very few things I use a Git GUI for. Git's command-line interface is just leagues better than SVN's. Not only is the msysgit GUI eye-rape, but when I was trying it out last week trying to checkout a branch would crash it. TortoiseGit is at least usable, although it's still pretty easy to mess up.
|
|
#
¿
Mar 9, 2010 18:29
|
|
|
Lysidas posted:I can't defend the GUI; I only use gitk. I've never experienced any instability or problems on Windows, especially not a crash (!) when trying to switch branches. The crash was through the GUI, with some of the GUI components, not gitk. Lysidas posted:Man up and use the CLI I really appreciate the Tortoise* explorer integration so I'd rather not.
|
|
#
¿
Mar 11, 2010 16:27
|
|
|
So I keep hearing that git/mercurial do better merging than SVN, but aside from the branch commit history (which I don't care about), I'm not really clear on why. Can someone provide/point me at a real world example where git/mercurial will perform the merge correctly and SVN will not?Janin posted:SVN doesn't support branching. I can't branch from the main repository to my workstation, make commits locally, and then merge them back. You have an interesting definition of branching.
|
|
#
¿
Mar 12, 2010 17:20
|
|
|
Mithaldu posted:TGit paired with Putty's pageant handles branching, diffing, logs, merging and most importantly, connectivity to remote repos with ssh keys completely transparently for you. Except it leaves pageant open, with a starting directory in wherever you first used it, which holds a file lock and prevents you from deleting/moving/renaming that folder. AutoCrLf handling is, at best, poor. It will mark files as modified immediately after checking them out, which will interfere with a lot of operations (no switching for you). I've had numerous operations mysteriously fail, and then succeed on the second try without doing anything differently. And other operations that failed for a good reason, but all TortoiseGit will give me is a pop-up dialog with a hex string in it.
|
|
#
¿
Mar 20, 2010 18:36
|
|
|
I only started using git a few weeks ago, so I've only used the current version of TortoiseGitOtto Skorzeny posted:You can't git stash away the (non)changes? I shall give that a try... And now I've got a shining example of TortoiseGit messages:
|
|
#
¿
Mar 21, 2010 02:26
|
|
|
Mithaldu posted:Now, the permission problem could be either an inability to create "examples", due to read-only on the base directory; "findnameindexes.cpp" due to read-only on "examples" or because "findnameindexes.cpp" already exists and is not read-only. There were 14 other files in the same folder that had no issues. I didn't have the file open in any program. This one particular file was, for no apparent reason, deleted. I was able to restore the file by reverting the the folder afterwords. Since I hadn't made any changes to the file, I don't know if anything would have been lost. Considering that I have never had SVN delete files on me, this didn't exactly convince me to hop on the Git train.
|
|
#
¿
Mar 21, 2010 21:03
|
|
|
You want to exclude the user specific stuff, like .suo, .vcproj.*.user, .ncb, which hold the pure IDE settings stuff, and the build directories. Changes the the sln or vcproj are generally going to affect how your project compiles, which is presumably important; it'd be no different than committing changes to your makefile.
|
|
#
¿
Oct 5, 2010 19:07
|
|
|
magic_toaster posted:I may be wrong, but this seems incorrect. One of the projects I'm working with right now is in a repository with 50 other projects. There's nothing wrong with that. magic_toaster posted:Additionally, being that databases is a different folder than applications, you can't associate a DB with a certain application. Why should application and database be a one to one correspondence?
|
|
#
¿
Dec 22, 2010 17:50
|
|
|
Factor Mystic posted:TGit reports success but doesn't ... This part of my experience a year ago is what really turned me off about TortoiseGit; when I did things wrong I'd often end up with a "Success" message containing details about the error, or just a line of hex.
|
|
#
¿
Apr 19, 2011 16:07
|
|
|
Lysidas posted:Carelessly using git add -p reminds me of Subversion's misfeature that allows you to commit changes as long as the files you've modified don't have any newer changes in the repository. That makes me very uneasy, again because you're committing a state that has never existed before and has no guarantees of working. Wait, what? There are VCSes that don't work that way? Having to redo the update, build and test any time another developer committed something before you committed sounds pretty awful. Edit: Suddenly SVN's poor performance seems so much more tolerable Zhentar fucked around with this message at 02:08 on Dec 10, 2011 |
|
#
¿
Dec 10, 2011 02:03
|
|
|
Suspicious Dish posted:No, I believe he means that if you modify files A, B, C and the latest version of the SVN repository has updates to D, E, F, you can commit the changes to A, B, C even if you don't have the changes from D, E, F, meaning that you potentially have this state where things won't work. I guess I was a little unclear - I did correctly understand what he was describing; I've been using SVN heavily for years. Even if it's just merging branches into trunk, it still sounds unmanageable to me.
|
|
#
¿
Dec 10, 2011 03:03
|
|
|
I can't offer any git specific advice, but KDiff3 is a pretty good GUI diff program for looking at things.
|
|
#
¿
Mar 5, 2012 04:46
|
|
|
You don't have to revert the entire repository. You can perform operations on items within it separately.
|
|
#
¿
May 3, 2012 19:03
|
|
|
I don't remember the article very well, but I do remember thinking it was pretty unreasonable. And that's coming from someone who had a decidedly poor Windows Git experience.
|
|
#
¿
May 21, 2012 20:42
|
|
|
Maybe I'm just one of those ignorant developers (or just missing something), but I would strongly consider using version control from the command line very much "not a fun experience".
|
|
#
¿
May 22, 2012 18:08
|
|
|
The newer VCSs are better at merging in some situations, but SVN isn't that bad. You're loving something up. From your example, it looks like you've had a merge conflict elsewhere in the file, and what you've shown is a non-conflicting merge section that's just in an intermediate state waiting for you to use a merge tool to resolve the conflict. I will recommend KDiff3 as a merge tool.
|
|
#
¿
Jul 16, 2012 21:11
|
|
|
wwb posted:SVN does not have a concept of shelve -- that is really a DCVS feature in my experience. Shelve is fairly high up on the SVN feature wishlist. It didn't make it into 1.8, but SVN 1.9 may well have it.
|
|
#
¿
Feb 26, 2013 19:25
|
|
|
That's a pretty good workflow for SVN too (except for pushing to production after one round of code review, yipes).
|
|
#
¿
Feb 28, 2013 23:43
|
|
|
People who think programming is fun tend to be more interested in solving interesting programming problems than boring business problems. So they usually come up with ways to turn boring business problems into interesting programming problems. This can turn out well, but it can also be a pretty bad thing. Edit: I'm a complete sucker. Most of my fun programming is owned by my employer, since it's spent working on code owned by my employer (Not the same code I work on for my day job, mind you).
|
|
#
¿
Jul 17, 2013 23:10
|
|
|
|
| # ¿ Apr 28, 2024 12:30 |
|
|
You should be able to just add the TortoiseSVN\bin directory to your PATH.
|
|
#
¿
Aug 8, 2013 23:09
|
|