|
Something is wrong with this reporistory and I don't know what. Server is 1.4.6, Client is 1.5.3 (tortoise). There's a directory, <root>/WEB-INF/classes which I don't want in the repo. So I delete it using tortoise (equivalent of `svn rm` I'm assuming), commit that change, then add an svn:ignore property to the <root>/WEB-INF directory (to ignore "classes"). When I build my project, the classes folder is created and populated, but instead of looking like it's ignored, it looks like there are changes (red exclamation point). Trying to commit from <root> I get "no files to commit", running an update on <root> yields no changes, however running an update on <root>/WEB-INF/classes brings in a load of .class files, reason is "Restored". What's going on here?
|
#
¿
May 27, 2009 20:55
|
|
|
|
| # ¿ May 2, 2024 08:38 |
|
|
"Ignore strange behavior" is not a real solution. Something is definitely wrong here, either in my understanding or in svn itself.
|
|
#
¿
May 28, 2009 14:21
|
|
|
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
|
|
|
BizarroAzrael posted:Would deleting the offending directory and doing an SVN update to restore it sort it out? I don't know. But you can move the file, try it, and move it back if it doesn't work.
|
|
#
¿
Mar 29, 2010 04:59
|
|
|
I'm trying to convert an svn repo to hg...code:Edit: I just realized 819 and 818 are revisions. Why didn't it start at 932, which is the latest in the svn repo? Edit2: It's done a few more revisions, counting down. Really, really slowly. Is it typical for hg convert to process 1 revision every 5-20 seconds? epswing fucked around with this message at 04:51 on Jun 18, 2010 |
|
#
¿
Jun 18, 2010 04:24
|
|
|
Finally got things converted and cloned and so forth. So my initial repo was created with 'hg convert' by hg 1.3.x, cloned to a central repo which is running hg 1.1.1, and I'm running hg 1.5.4 on my desktop. are there issues with running all these different versions?
|
|
#
¿
Jun 18, 2010 21:47
|
|
|
Mercurial (or DVCS in general) question. I have a few contractors writing code for me. I'm thinking of this architecture: code:I'm new to distributed version control, but I think this makes sense. Educate me! How does this sound? How should code get from them to me, i.e. should I be Pulling from them or should they be Pushing to me? Or using patches? Does it matter? Edit: I should add that my goal is to preview/test their work in my development environment before allowing it into the central repo, but if it does get into central I want their history preserved. epswing fucked around with this message at 04:25 on Jun 29, 2010 |
|
#
¿
Jun 29, 2010 04:00
|
|
|
ColdPie posted:You don't want them pushing to your repository, you should be pulling from theirs. Why is that? I ask because allowing them to push to me seems like a reasonable approach when dealing with a small number of people. Even with push_ssl = False and allow_push = *, can't I flip on hg serve, accept the push, and flip it off again? No ssl issues, no extra public/private keys (other than the ones required for them to pull from Central), they aren't required to forward a port through their router to allow hg serve to work on their machines (only I need to do this), no extra external repos. The only downside I see is that we have to both be at our machines at the same time, or work out a schedule ("My machine will be available to accept your push from 9-10pm tonight"). Please tell me if I'm being an idiot...but this seems viable for small groups, no? epswing fucked around with this message at 06:45 on Jun 29, 2010 |
|
#
¿
Jun 29, 2010 05:32
|
|
|
I should have clarified that I'd have a clone specifically for accepting changes. In fact I could have as many clones as I have pushing developers, each hg serveing on a different port. However...I see what you're saying. It makes sense that I would clone from them so I can load their changes into my development environment, and then if I liked what I saw, I'd actually pull into my working repo.
|
|
#
¿
Jun 29, 2010 16:24
|
|
|
Lysidas posted:So one public repository per developer (read/write) and one public central repository (read-only). By public I mean 'available on the internet'. That makes sense. So I can take a look at their changes, and be able to push from their public repo to the central repo. code:Edit: Riiight, like this 
epswing fucked around with this message at 18:34 on Jun 29, 2010 |
|
#
¿
Jun 29, 2010 18:15
|
|
|
I don't normally do this but...king_kilr posted:branches branch's directory's Learn and understand the difference or you'll be confusing people for generations.
|
|
#
¿
Jul 19, 2010 14:48
|
|
|
Redmine integrates with SVN (and others) and does those things.
|
|
#
¿
Jul 19, 2010 21:14
|
|
|
I've convinced the team to switch to Mercurial! Yay! We have a bunch of repositories on a server (windows box), one for each project. So now it's time for linuxy programmer to become windowsy IT guy, because "I advocated for the stupid thing, so I better make it work." I've been using TortoiseHG to launch the graphical webserver for each, giving each one its own port (8000, 8001, etc), clicking the "Start" button on each. Screw that, so I now have a batch file that looks like this pre:cd D:\hg\Project1 hg serve -d -p 8000 cd D:\hg\Project2 hg serve -d -p 8001 ... cd D:\hg\ProjectN hg serve -d -p (8000 + N) There's this thing http://mercurial.selenic.com/wiki/HgService but it looks like it can only run one server at a time ("WorkingDirectory the repository folder, if it's not specified it takes the install directory"). Am I going about this the wrong way?
|
|
#
¿
Oct 5, 2010 17:38
|
|
|
Next question: Visual Studio 2010 and version control. Background: I'm coming from eclipse/gedit/vi. Normally I just set my VCS to ignore the .settings folder and whatever else eclipse dumps into the root of my project. The idea is that anyone could use any ide/editor at any time, so don't push any ide-specific files into the repo. Makes sense. In the case of a C++ app written with VS 2010, I get the feeling that the code is pretty much married to the ide/compiler. No one is ever going to use anything but VS 2010. Thing is, any time there's any kind of change to the settings, or compiler options, or anything really, a few ide-specific files change such as MyProject.sln, MyProject.vcproj, etc. So...what do I do here? If I ignore these, my co-workers can't launch their project upon checkout. If I include them, a good number of commits will contain ide-specific files/changes. vvv E: much thanks epswing fucked around with this message at 21:06 on Oct 5, 2010 |
|
#
¿
Oct 5, 2010 17:50
|
|
|
uXs posted:Personally I just use a shared folder (on a server) and push/pull over network shares Aww dammit, I forgot that you can just point to a folder on a share and blamo. This is what we're going to do for sure, at least for now. Thanks!
|
|
#
¿
Oct 6, 2010 03:19
|
|
|
Nothing's wrong with that plan, except at my new job there isn't a single linux machine in the building.
|
|
#
¿
Oct 6, 2010 15:40
|
|
|
Actually I've been meaning to look into self-contained applications/stacks provided by http://bitnami.org/. Looks promising, actually...
|
|
#
¿
Oct 7, 2010 07:22
|
|
|
Mercurial question. I'm happily developing along, tagging as I go, 1.0, 1.1, 1.2, 2.0, 2.1. Then I realize there's a bug in the 1.x line, so I need to fix that and merge the fix into 2.1: clone to -r 1.2 do some work, commit add tag 1.3 pull (I'll get multiple heads here) merge* commit push That merge will always give me a .hgtags merge conflict. I simply keep the changes from both sources and things work fine (does the order of the lines in .hgtags matter?). However if I instead clone to the revision after -r 1.2 and follow the steps above, there isn't any .hgtags conflict. So when I go back to fix something, should I clone to the tag I want, or one rev after the tag I want? Aside: I love mercurial, and will probably name my first born "mercurial", but having tags as changesets seems unintuitive. Why are they versioned?
|
|
#
¿
Oct 15, 2010 17:16
|
|
|
Is the method to add all new files to svn still some bullshit like svn status | grep "^\?" | awk '{print $2}' | xargs svn add
|
|
#
¿
Nov 2, 2010 02:30
|
|
|
Sizzlechest posted:svn add --force . But this will ignore svn:ignore 
|
|
#
¿
Nov 2, 2010 03:33
|
|
|
What's wrong with a server doing pull/update to a specific revision? What script would you write that doesn't involve this?
|
|
#
¿
Nov 18, 2010 05:34
|
|
|
My question got skipped http://forums.somethingawful.com/showthread.php?threadid=3113983&pagenumber=15&perpage=40#post383276306 When going back to fix a bug in an old tagged version, and merging back into the main line of development, shouldn't I clone/update to the rev after the tag to avoid that pesky .hgtags merge conflict?
|
|
#
¿
Dec 13, 2010 15:54
|
|
|
Mercurial Wiki:quote:The fact that tags identify changesets and are also parts of changesets has some potentially confusing implications: Mercurial Guide: quote:An unfortunate consequence of this design is that you can't actually verify that your merged .hgtags file is correct until after you've committed a change. So if you find yourself resolving a conflict on .hgtags during a merge, be sure to run hg tags after you commit. If it finds an error in the .hgtags file, it will report the location of the error, which you can then fix and commit. You should then run hg tags again, just to be sure that your fix is correct. Do you generally find versioned tags useful, or is this an over-engineered "feature" that you find annoying? epswing fucked around with this message at 17:15 on Dec 13, 2010 |
|
#
¿
Dec 13, 2010 17:10
|
|
|
pre:4.0.0 4.1.0 4.2.0 4.3.0
--o----o----o----o----o----o----o----o----o----o--
\ /
\ 4.0.1 /
-----o---------------------------
I've merged a fix from an old release into the main line of development, which will be released as 4.3.0, that's all good. What about clients of mine that are in between, running 4.1.0 and 4.2.0? Don't they need the fix too, released as 4.1.1 and 4.2.1? I'm not sure how I can merge the fix into both the main line of development, AND intermediate minor builds. We're using mercurial. Is this what mercurial's "branches" are for? epswing fucked around with this message at 20:32 on Jan 12, 2011 |
|
#
¿
Jan 12, 2011 20:18
|
|
|
bitprophet posted:re-applying that patch to 4.1 and 4.2 This right here is the missing link in my brain, how do I do this? Actually it might become clear after I finish reading about branches.
|
|
#
¿
Jan 12, 2011 22:32
|
|
|
I feel like this should be somewhere right in front of me but I'm not seeing it. Using tortoisehg, how can I visually compare a file to an earlier version of itself? Using whatever, kdiff3 or WinMerge. I want to initiate this from the Repository Explorer. Edit: Basically if I add code:code:epswing fucked around with this message at 15:08 on Mar 31, 2011 |
|
#
¿
Mar 31, 2011 14:47
|
|
|
Your article should be titled "Why I Don’t Like the Git Installer" which basically has nothing to do with Git as a source control application. While you have some valid points about the installer as a first-time user, you later say quote:...Git has a two-step method of checking in source. First, you check in your source in your local repository. Second, you merge your local repository with a server. While there are definite pros and cons to this approach that are most certainly debatable, the only thing I see in the practical sense is that, with Git, I need to take two steps whereas I can get the same result with SVN in one step...
|
|
#
¿
Apr 14, 2011 18:35
|
|
|
Janin posted:Visual Studio: Windows only 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)
|
|
#
¿
Apr 21, 2011 17:17
|
|
|
Mithaldu posted:Jesus Christ, you two should marry. You're the perfect pair with one of you claiming only linux users can be developers and the other claiming that most developers prefer windows. What if Captain Corny and Janin are the same person with multiple personality disorder?
|
|
#
¿
Apr 21, 2011 20:59
|
|
|
You're kind of guessing what's wrong and trying different things. When you say the PHP script "fails silently"...is it 500'ing? If so, what does the web server's error.log say? If not, wrap the whole thing in try/catch and write the $exception to a file or something.
|
|
#
¿
Apr 26, 2011 15:17
|
|
|
Modern Pragmatist posted:Ok that's what I assumed was the case. So I would include build but not dist. Yes
|
|
#
¿
Apr 28, 2011 19:48
|
|
|
devilmouse posted:Perforce -> Mercurial Define 'changelist'. Edit: Oh, if you mean you're working on different features at the same time, then sure you could use branches, or you could also clone your repo for each feature.
|
|
#
¿
May 2, 2011 15:51
|
|
|
I haven't used the git gui in 6 months, but if nothing's changed I think tortoisehg knocks it out of the park. (P.S. I'm not saying the git gui doesn't work fine.) E: Oh poo poo I just participated in a holy war please ignore this post entirely 
epswing fucked around with this message at 20:06 on Aug 17, 2011 |
|
#
¿
Aug 17, 2011 20:04
|
|
|
Misogynist posted:Performance isn't good, but I haven't run into any other problems. Qualify this statement, please. I think you just did.
|
|
#
¿
Aug 18, 2011 14:24
|
|
|
wwb posted:Bigger issue I've got with DCVS is that it is very, very hard for the non-developers to grok I begrudgingly opted for SVN instead of a DVCS because I didn't want to deal with teaching the designers how DVCS works. (They barely get SVN.) I thought about maybe writing a couple shortcut scripts to "commit and push", and "pull and update", but that would almost certainly explode in my face. Can't tell yet if it's going to be worse if (when) SVN explodes in my face. 
|
|
#
¿
Aug 18, 2011 14:56
|
|
|
Maybe you want to comment/elaborate on what this is and why everyone should be using it, rather than "betterusethiskbye"?
|
|
#
¿
Sep 4, 2011 18:49
|
|
|
I use something like that template method you mentioned. Say my config file is named config.xml. I tell version control to ignore that file (because it's going to be different for my environment versus another developer's versus the production environment, etc) and I create (and version) a file config.xml.tmpl. It contains a line like: pre:SECREY_KEY=~~SECRET_KEY~~ At that point I usually write a script to inject/replace (via sed, or ant's replace task, etc) all the ~~BLAH~~ parts of config.xml, so I can clone, rename the config file, inject appropriate values, and deploy the project in one click. Not sure why you'd need a special class in your code... epswing fucked around with this message at 14:50 on Oct 4, 2011 |
|
#
¿
Oct 4, 2011 14:40
|
|
|
Xik posted:When you distribute a binary your secret key will be viewable to the end user if it is stored in a config file, unless I'm missing something completely obvious (very likely). Oh, I see, this isn't a web-app (or other centralized program). Sorry, I didn't read closely enough. The api key is for some service your program uses? Why can't the end users get their own api key? Or if that's not feasible, you could host your own proxy service which always uses your api key to the actual service, and you provide each client with their own api key to your proxy service. Not saying these are great ideas, I don't know what your program does, nor what the api is even for. vvv E: Yeah, Xik, you can't "hide" your key in a binary, I forgot to mention. epswing fucked around with this message at 19:02 on Oct 4, 2011 |
|
#
¿
Oct 4, 2011 18:32
|
|
|
I've been using mercurial for a couple years now, mostly for small projects with a small number of people working on them. Can someone explain to me the usefulness of in-repo branches? Our workflow is as follows. There's a central repo which I clone onto my machine. I don't work on that clone though, I treat it as my "main" repo, which is the only one which will have changes sync'd with the central repo. I then clone my main repo whenever I have to work on something (a bug, a feature, etc). So my "feature branch" is just another clone of my main repo. code:
|
|
#
¿
Oct 18, 2011 18:55
|
|
|
|
| # ¿ May 2, 2024 08:38 |
|
|
MEAT TREAT posted:I'm using branches to collaborate with another remote developer. We don't have access to each others machines, so we share our changes through the main server. If a third developer wanted to check out our stuff he can just switch to the branch instead of having to ask us to share. I don't quite understand this (probably because of my lack of experience with mercurial). There's a main server, what wouldn't a 3rd dev have access to if you didn't use branches? uXs posted:Bugfixes on code that is running in production somewhere. Pull from central repo into my main repo. Clone my main repo, update back to the tagged version running in production, fix the code, commit, merge the fix into tip, and push the fix back into my main repo. Which gets pulled into the central repo. I don't need branches for this workflow. And "other work" isn't affected because I'm working on other work in other clones. Mithaldu posted:Being able to switch between branches within less than a second without having to mess around with different directories? This isn't a great reason. It's pretty much the same functionality. I guess someone might not want having a number of clones (directories) lying around, but then again sometimes I do, because I want to run two versions of the program concurrently, maybe I'm trying to compare something. Edit: I want to be clear, I'm not saying "I hate branches", or "branches are bad for you", or anything like that. I'm asking what is their benefit over just cloning? Seems the same to me. epswing fucked around with this message at 21:15 on Oct 18, 2011 |
|
#
¿
Oct 18, 2011 21:09
|
|