1,453 reputation
513
bio website linkedin.com/in/aleschinsky
location Russia
age 49
visits member for 3 years, 2 months
seen yesterday

Admin, programmer, PM, dreamer, postmaster, bummer, standpatter, misanthrope


Jan
4
comment Git-friendly spreadsheet format?
@AlexanderGladysh - just use The Right Tool (tm). For XML it's Altova DiffDog. It's not a Git problem per se, but used differ-merger, which can be extension-specific
Jan
4
comment Git-friendly spreadsheet format?
@AlexanderGladysh - 1. LibreOffice works on Linux. 2. XML is not "MS-bullshit"
Dec
19
answered Wiki/markup in enterprise as documentation
Dec
7
comment Is there tool agnostic terminology for source control activities?
@mattnz - it's a question to hypothetical "Acme RCS 1.0"... Conventional terminology (I think) exist - everybody here, from different today's SCMs, understand users, when (if) they use "check-in" as synonym for "commit". But less part can grok Git-boys, when they start to speak on "gitish" exclusively
Dec
7
comment Is there tool agnostic terminology for source control activities?
@kaz - "but it can be not repo (in CVCS), and local repo can be not .< whatever > subdir in WC", sorry, if you want fair play here. Git working directory and repository are separate objects
Dec
7
answered Looking for best practice for version numbering of dependent software components
Dec
6
comment Is there tool agnostic terminology for source control activities?
Gitboys... Oh, God, no, please!!! Except fact of unwanted ads here, Git actively refuse to use conventional revision control terminology. "Sorry, you use checkout to revert a commit? And checkout also switches between branches? revert is like a merge? WTF?" (c) André Pang
Dec
6
comment Is there tool agnostic terminology for source control activities?
@Kaz - in Bazaar, "checkout" exist in two forms: verb and noun. Verb meaning is equal to other "conventional" SCMs: ... each person should use the checkout command to create their local checkout, i.e. the sandbox in which they will make their changes..."
Dec
6
comment Is there tool agnostic terminology for source control activities?
@Kaz: WTF??? Local repo in git physically - .git dir inside Working Copy
Dec
5
comment Is there tool agnostic terminology for source control activities?
@mouviciel: [clearcase] have ~1 q/day here, 5% (5.2%)in UK job-offers. First-class? Vs Subversion - 45.3%, TFS - 21.3%, Git - 16.2%???
Dec
5
comment Is there tool agnostic terminology for source control activities?
... and Bazaar and Fossil. >50% of market share can't be "misleading", kid!
Dec
5
comment Is there tool agnostic terminology for source control activities?
update is equal in SVN and Mercurial. svn up ID == hg up ID: svn - "Bring changes from the repository into the working copy", Mercurial - "Update the repository's working directory to the specified changeset". RTFM
Dec
5
comment Is there tool agnostic terminology for source control activities?
@MasonWheeler - checkout is initial getting of code from Repository into Working Copy. Update is traversing over history of Revisions and changing active point in Working Copy
Dec
5
answered Is there tool agnostic terminology for source control activities?
Nov
30
answered Strategy for versioning on a public repo
Nov
24
comment Agile project management, agile development: early integration
@MatíasFidemraizer - 3 days of pure development + 1 day of integration < 3 + 3 (at least) of parallel work (50% of speed degradation in task-switching is good result). But "non-fundamental changes" have to be integrated ASAP
Nov
24
comment Agile project management, agile development: early integration
@MatíasFidemraizer - where did I say about "last minute integration"?!
Nov
24
comment Agile project management, agile development: early integration
@MatíasFidemraizer - "When one breaks the build, what about buying some cookies for the rest of the team?" - I hate this yankee-games: Errare humanum est! "What's the advantage of having a "future broken code" not broken for now?" - Let's solve problems as they arise, Merge conflicts are problems of merge time, code disfunction are problems of integration time. Agile is just method and toolset, not god
Nov
23
comment Agile project management, agile development: early integration
@MatíasFidemraizer - well, we all have different habits and style of programming: when I starting write code, I have ready solution, which I just convert into code (and later, if it was big task, adopt to changed core) in my own isolated (sic!) shelve. If world was changed, I'll change it's citizen. Adopting WIP-solution to WIP-core in parallel may be cumbersome and endless task (and may not be). And yes, I guarantee that my code, merged to mainline, pass all tests, doesn't broke builds and comply all any other reqs of Coding Policy - I'm a developer, not code-monkey
Nov
23
comment Agile project management, agile development: early integration
"Programmers should get latest before they start a task, and before they commit code for a task" - WHY ??? I wrote code, based on old codebase, I have functioning code, I save it and only after it I'll merge it with latest changes - not the easiest way, but it have rights to live