What are the best practices today regarding dealing with line endings in mercurial? The HGEOL extension wiki page says it is a "feature of last resort" which tells me it should be avoided, however, I'm not aware of an alternative. If HGEOL extension is the best way to go then what are the best practices for configuring it?
"feature of last resort" DOES NOT mean "...should be avoided" - you have to improve your logic-skill, definitely (or language: "last resort" is more "Ultima ratio regum" than "damned bullshit for loosers") - your own mileage may vary
It's personal opinion of Mercurial developers - your own mileage may vary
Instead of technical solution anybody can have and prefer administrative methods: in cross-platform environment 1) define 2) declare 3) control 4) enforce usage of uniform EOL-style by every developer on every workplace regardless of native default OS settings. I consider this solution as a managerial delirium (subject to human errors, not bullet-proof) and developers nightmare - your own mileage may vary
Related
Very soon we are going to start on open-source (py+qt) project which is supposed to be multi-platform (we're using FreeBSD as native platform) and we're not sure which DVCS/hosting to use.
In the past we were using darcs for very long time, but moved away from it due to not having adequate public hosting available. Played for some time with Monotone - nicely designed, but mostly niche today. Fossil is nice, but it uses non-standard wiki and its tracker is functional, but we expect more.
Considering that we won't work on kernel-like sized project we do not nee Git which we consider too complex to deal with it, especially for potential contributors which might use Windows OS and prefer GUI tools.
So, the story comes to Bazaar/Launchpad and Mercurial/Bitbucket...
Here are some pro/cons which we gathered together, but would like to hear if we missed something which might help us to decide...
Bazaar pro/cons:
2.4 is probably quick enough for our needs ,
simple to use,
has nice GUI tool (explorer),
handles empty directories,
(probably) less popular than Mercurial,
does not have equivalent of hg's named branches
The last point is probably not to important 'cause there are nicks and there is colo-branches plugin, so one can get same/similar functionality.
The most problematic quirk we find in Bazaar it its revision numbers scheme and problem which can arise if one pushes from feature branch into upstream which would change revids.
Maybe it's a lesser problem when using Launchpad...
As far s Launchpad is concerned:
- it has very nice bug tracker with email interface
- it's (maybe) more project-oriented than Bitbucket
- no private repos as with Bitbucket
- no wiki for projects - bug (https://bugs.launchpad.net/launchpad/+bug/240067) is more than 3 years old and still with 'Low priority'. LP is the only one amongst {LP,Sourceforge,Bitbucket, Google, Github} which lacks this feature and it really sucks and degrades, otherwise, nice hosting solution.
What we've found in The other camp...
Mercurial is:
(probably) more popular than Bazaar,
quick,
simple to use,
there is nice TortoiseHG for non cli-savvy users,
we like named branches,
some quirks like handling empty directories (or https://www.mercurial-scm.org/bts/issue29)
However, what we like the most over Bazaar is, as we believe, great merging capabilities without the hassle of changed revids due to revno:hash schema.
As far as Bitbucket:
we like to have unlimited/private repos
we like having wikis available for the project(s)
we miss email interface for the tracker and the tracker is (maybe) not on par with the one at LP (reviews etc.)
At the end, let's say that there are some projects which we are interested in which are under Git #github, so we would like to use single DVCS which can helps us inter-operate with git#github projects.
We find that bzr-git plugin is very capable and do not have experience with hg-git.
Although there is bzr-hg plugin (not as mature as bzr-git), but we do not know about something like hg-bzr except hg's convert extension which does the job of hg-bzr conversion.
Is there any important feature which we did miss having important consequence in deciding about the two?
Finally, we use DVCS for all our needs (simple project, writings...) and we'd prefer to settle on one DVCS/hosting which can serve all our purposes and be useful in contributing to git(hub) projects as well.
What do you recommend?
In Bazaar:
You can avoid the problem of revision numbers being renumbered by setting append_revisions_only in branch.conf, which will make sure people only merge into trunk, rather than switching the trunk around.
I like bzr-colo a lot for dealing with named colocated branches.
I would certainly like to see Launchpad get wikis. It's assigned and in progress at the moment so perhaps it will get done soon.
Update: Seing this comment makes it easier for us to abandon bzr/LP and embrace hg/bitbucket.
I just saw this term on a job I was applying for and I'm not entirely certain what it means. If I had to take a guess at it I'd say it means supporting end users of other vendors software, but I'm not entirely sure about that.
To give you some context the job is at a hospital as a web developer/technical analyst.
I see that as similar to what you state but with a small caveat. I suspect it's just experience with application support with a vendor (not another vendor).
In other words, they're looking for the fact that you worked for Dodgy Brothers Software Ltd in supporting their top-of-the-line application, BCPL Toolkit.
You'll probably be quizzed about how customers raised faults, how they were prioritised, how they were classified as bugs or feature requests, how they were tracked, developed, tested, deployed and so forth.
It sounds like they want you to be a pseudo-third-party product provider at this hospital, not a bad idea since it will probably provide a fair bit of autonomy (it would be unusual to treat you as "separate" while still maintaining a tight control on how you do your job. Of course, like any vendor-customer relationship, they still control the purse-strings so autonomy is a two-edged sword.
The other possibility is that they're just looking for experience with dealing with vendors (if they want you to evaluate/integrate real third-party products).
But I see that as less likely since that would less call for "Vendor Application Support" and more call for tendering, requirements and evaluation skills which you don't mention.
And remember that almost any experience can be subtly morphed into exactly what the employer requires :-)
Personally, I use the word "patch" as the software equivalent of a symptomatic treatment, which makes a patch a quick-and-dirty bugfix. However, I'm not sure this is correct, because I often see it is used in other meanings, for example as a synonym of a program update.
What does the word "patch" mean exactly?
Update: I think terminology does matter a lot, because it is a fundamental aspect of documentation and communication, and therefore of software development in general. The problem is that computer lingo is defined rather loosely, and I don't know which dictionary provides the definite reference. Therefore I thought it was a good idea to ask this here on StackOverflow.
From Wikipedia:
A patch is a piece of software
designed to fix problems with, or
update a computer program or its
supporting data. This includes fixing
security vulnerabilities and other
bugs, and improving the usability or
performance. Though meant to fix
problems, poorly designed patches can
sometimes introduce new problems (see
software regressions).
You can find the definitions in the Jargon File: patch. Your personal usage of the term seems to fall under 1, while generally the word "patch" has become a strong synonym for "diff" in recent years.
Apart from that, I'm with S.Lott on this one: what does it matter?
In the open source area, a patch is a means of communicating amongst developers. The patch itself is a machine and human readable piece of text describing changes to source code.
The word patch itself has no connotation of "quick and dirty", or a "fix" in this context. It just is a change to source code.
Search terms for further research: diff, patch
I'm currently trying to evaluate Mercurial, to get a feel for the philosophy the system tries to promote - but one thing that's got me confused is the presence of the bundled 'extensions' and how they fit into the mix.
In the core package, Mercurial ships with a bunch of functionality that is implemented as extensions but is disabled by default. (See: https://www.mercurial-scm.org/wiki/UsingExtensions#Extensions_Bundled_with_Mercurial)
Here's the thing I'm confused about:
Are these extensions considered first class citizens by the Mercurial dev team and therefore part of the overall Mercurial approach to DVCS?
Why are they implemented outside of the default features and disabled by default?
I don't need info on how activate extensions, that's pretty straight forward - it's the logic behind the separation that I'm curious about.
The reason I'm trying to get my head around this is because I don't really want to try and crowbar an opposing approach into Mercurial via extensions if it differs from the overall philosophy of the project.
Are these extensions considered first class citizens by the Mercurial dev team and therefore part of the overall Mercurial approach to DVCS?
Yes, although we won't generally advocate their use to new users, they are very useful for advanced usage. I guess everybody in the dev team has extension enabled (at least mq, patchbomb, and sometimes record).
Extension accepted in hgext/ are reviewed priori to inclusion, and we generally require them to provides tests. But they are often owned by outside contributors and aren't updated by the dev team except for API changes within core hg.
Why are they implemented outside of the default features and disabled by default?
We generally think that hg should stay simple and adding more commands might confuse users (e.g. if you have a simple workflow you don't need to learn about mq). But if a command is deemed useful for most users, it can migrate from an extension into core (that was the case for bisect, and it is the case of the subrepo functionality).
Almost immediately after posting, I learnt about the following hg command:
hg help extensions
This contained some information that I don't think is available in the Mercurial help docs:
Extensions are not loaded by default for a variety of reasons: they can increase startup overhead; they may be meant for advanced usage only; they may provide potentially dangerous abilities (such as letting you destroy or modify history); they might not be ready for prime time; or they may alter some usual behaviors of stock Mercurial. It is thus up to the user to activate extensions as needed.
This helps answer part of my question.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
When trying to link some well established tools to my company's active directory, I hit a roadblock. I was told that:
"Sorry, I cannot trust our domain admin password to [F/OSS] software...".
This question deals specifically with how to convince IT that F/OSS software isn't (automatically) less trustworthy than any other software just because it's free/oss.
I'm doing fine with adopting OSS software (I'm a linux ninja at heart) so to put it another way: How can I promote the acceptance of OSS at my company?
The technical issue of tying into AD without an admin account is for another post.
EDIT:
I got some clarification on these issues. This really has little to do with the active directory and all to do with trust of F/OSS in general. So I think my original bolded questions are still valid, just ignore the part about the "admin password".
Any IT person worth their salt will be well aware of the benefits of open source software.
The answer that has been given sounds to me like a palm off answer, some possibilities of why they don't want to implement it could be:
Possible lack of enterprise level support for that specific software open source software
Not wanting non-IT department employees to be modifying the active directory (you)
The software you have found doesn't have the industry recognition that other similar products have
There is no perceived benefit for the IT department for the work it would require them to do (both in the initial setup and ongoing maintenance)
I work as a sysadmin. From my perspective this question isn't about trusting Open Source software specifically. Your IT person mentioned a specific case saying he didn't trust it with the domain admin username and password. I think he may be concerned with the software storing that username and password. If that is in fact how it works I would deny the request for open source or commercial software. No properly setup system should need to store the domain admin username and password, possibly an account with lower credentials, or depending on the tool if it is interactive have it setup to ask for credentials at runtime and authentcate against the domain.
Bottom line you need to work with IT to come to a better understanding of your and their needs. Things need not always be only a yes or no issue.
I would try it this way:
Why would open-source software be less trustworthy than it's close-sourced equivalent? If anything, the transparency of its code would require that it be even more trustworthy, in terms of private data storage such as passwords, since any attempt to subvert it would be discoverable by examining the source code.
This, of course, is only valid if the company compiles the source themselves, and does not trust a binary distribution.
Ask them if they have read the license since that is what they object too. Ask them specifically what in the license is an issue for them. If what they are really resisting is Open Source Software, then that is a separate issue from resisting the GPL.
Why not run as a non domain admin? I can understand why they don't want to give a domain admin password to any software. Especially if there is only one "Domain Admin" account.
How about you determine exactly the permissions needed to run the software and request a new account with only those permissions. You could convice them to put this in a different OU, with additional auditing. If the software provides value, you are creating a process for them to "audit" and decide to trust OSS.
Identify exactly what he cannot trust about F/OSS software and then you can tailor your explanation to address his concerns.
Is it concern about backdoors being coded in?
Is it concern about code quality that leads to security risks?
Is it concern about how soon security risks will be fixed?
"how to convince IT that F/OSS software isn't (automatically) less trustworthy than any other software just because it's free/oss."
"How can I promote the acceptance of OSS at my company?"
You can't.
All you can do is the following.
Find the F/OSS they currently use. This can be hard. In some cases, it's trivial because many folks use Apache and Java without thinking about it.
Ask how is what you're going to use different than what they're already using?
That will make the case for exactly one new piece of F/OSS. Or, they'll go crazy and banish stuff they've been using.
You can't make a general understanding happen. You can only make the case one specific detailed case at a time until someone else starts to piece the big picture together on their own.
Sometimes they are not, sometimes they are. You need evidence to backup your thoughts.
CVE numbers don't lie. Go to http://cve.mitre.org/ , http://www.securityfocus.com/bid/, http://www.secunia.com and compare commercial and OSS version of the same line of products that you'd choose.
See which one is better sometimes it's the fact that the OSS product is really rubbish such as PHPNuke but sometimes it's darn good when it comes to security such as qmail.
Also don't forget you need to choose a OSS solution which got a good community otherwise you might see the project is dead after a year. this is possible in the commercial world, but let's face it less likely
I would put the onus on IT to prove their case. Simply ask "why not?", or possibly "what evidence do you have that this is any less secure than non-GPL software?". If they attempt to give some explanation, you can take some of the other suggestions to explain their misconceptions to them. If they just stubbornly stand their ground, they are standing in the way of you doing your job - and for no good reason. Gently explain to them how you have found incredible value (ie free) software that adds value to the company, and that you're sure the higher levels of management would want you to take advantage of it. Hopefully this will remind them they have no evidence. If even this fails and it's important, you could then take it to higher levels of management, but proceed with caution as it's a sure fire way to make enemies.
What tools do you want to use? Make the business case about how much time/$$ will be saved by using these tools. Give examples of other, highly-successful companies (Google comes to mind) that use these tools.
First and most importantly, make sure these decisions by IT are being recorded somewhere. Email or whatever. If you can't do your job effectively because of them, make sure you have enough documentation to redirect the blame where it belongs.
Look beyond IT. Your sysadmin may be following rules set down somewhere else in the company, typically a legal department. If that's the case, you may have a company lawyer who doesn't know about software or FOSS reacting with a corporate lawyer's typical reaction to the unknown - forbid it. After you've demonstrated cost and security benefits, you may need to ask the company to reach out to a legal expert in the area of FOSS.
You're talking about Windows admins. Just point out how MSFT has handled recent security issues (like the recent IE holes that have mainstream media telling people to use alternate browsers) and ask how OSS can be any worse.