50 Versions of Shed Control Wars
-
Can you be more specific?
I already posted about the ways locking can fail.
tl;dr the people getting locked out have to know about it for the system to work
-
Branches are another topic altogether.
No, they really aren't. They're just another dimension to "robust." At least, AFAIC, they're not changing the topic, but we seem to have different ideas about robustness.
-
-
FTFY
i guess... i actually just wanted to edit the title and was impatient about waiting for someone else to post 300 so i could accurately title the topic.
-
Touché.
-
By most accounts I have a pretty darn strict approach to robustness....
OK, so if we want to include branching, then I see two distinct scenarios:
- People cant work on the code without breaking it, so they use branches as a crutch.
- Multiple versions must be "production" supported over fairly long intervals.
The first I will exclude as that immediately shows that the environment is not robust.
The second is interesting. Under many circumstances the amount of work that must be performed in the "legacy" branches should be minimal. Work will fall into one of two categories:
a) The code is nearly identical between the branches. Therefore tools can be used to (help) keep things coordinated.
b) The code differs significantly between the branches and the implementations of equivilant fixes will be different.For both cases, I strongly prefer to do the coordination at the work tracking level rather than at the code level.
-
It is a subset of my normal comparison of CVCS vs. DVCS (regardless of actual tool). If you get benefit from having a central point (which typically implies having reliable connectivity) then go with a CVCS. I find this to be "the truth" for most business/corporate environments.
The gripe here is that Git could easily fill both those roles, if it hadn't been coded by incompetent dickholes. Easily.
This is like arguing electric vs. gas cars and utterly ignoring that hybrid cars can potentially be more successful than either. CAR ANALOGY!
And I would like to reiterate that FinalBuilder files are both binary files and source code. I'm sure there are a dozen other examples, too.
-
impatient about waiting for someone else to post 300 so i could accurately title the topic.
Now I think I understand why you liked my bikeshed post on the status thread... ;<cvbn>D
-
well that and the changing the colour via subdomain was absolute genius!
-
[i]binary files[/i]
I don't think I've ever worked on a codebase which didn't have a large number of binary/media/art files checked in along with the source code.
Actually, no, I do remember one, where you'd sync and build the code and then go off and hunt down the approppriate assets off of a shared drive—that was a horrible workflow. Sucks to spend 10 minutes copying art only to find that it's not compatible with my current source code and I need a different version. (Maybe the art that's compatible with head hasn't finished building yet?)
-
@blakey - Please explain to me (and use little words) how anything can be BOTH "centralized" (where all activity is trackable at any point in time) and "distributed" (where changes can be made without connectivity)???
If you have a (non-abusive) workflow where a person can start working on something without everyone involved being able to see that the work is starting (and in most cases getting a notification via e-mail, if desired)..then it is not truly centralized...
If you have a requirement where there is always connectivity to a central location, then it is not distributed!
-
I'm sure there are a dozen other examples, too.
Any project of decent size is going to have assets (code, media, etc) in different formats that need to be processed and combined to build the final product. These assets are going to be created by people collaborating. That collaboration needs to be coordinated and synchronized in some manner for the team to work effectively.
Saying you shouldn't put binary files in the CVS just means that instead of one store for the project, you need to have several systems. It's not offering a solution, it's just refusing to acknowledge the problem and washing your hands of it. It's putting the design of the system above the needs of the user. It's a poor stance to take.
People are going to use the CVS to store binary files because the CVS already does 90% of everything they need, and adding more systems increases the complexity of the build system. Refusing to acknowledge how your users use your system because it's not how you want them to is following the Discourse school of design, where the users are "DOING IT WRONG" for failing to appreciate the genius of your design.
-
@blakey - Please explain to me (and use little words) how anything can be BOTH "centralized" (where all activity is trackable at any point in time) and "distributed" (where changes can be made without connectivity)???
It can be one or the other at different times and within different domains. A distributed system can fake being centralized, but a centralized can't fake being distributed, so it's annoying when the distributed system refuses to offer regular tools found in centralized systems because it soils the purity of the distributed approach.
-
The gripe here is that Git could easily fill both those roles, if it hadn't been coded by incompetent dickholes. Easily.
I think we've disproved this before, but could you please explain how they could do it "easily?"
-
I think we've disproved this before, but could you please explain how
they could do it "easily?"blakeyrat would do itFTFY.
;-)
-
@blakey - Please explain to me (and use little words) how anything can be BOTH "centralized" (where all activity is trackable at any point in time) and "distributed" (where changes can be made without connectivity)???
It doesn't have to be both simultaneously.
ANSWERED MOTHERFUCKER.
-
I think we've disproved this before, but could you please explain how they could do it "easily?"
I'm not saying it would be trivial, I'm saying it's not "impossible", like the idiots in this thread keep bringing up.
BTW, the sentence you coded said Git could "easily fill those roles", not "modifying Git to fill both those roles would be easy". I SUGGEST REMEDIAL 4TH GRADE READING LESSONS.
-
-
I'm not saying it would be trivial, I'm saying it's not "impossible", like the idiots in this thread keep bringing up.
You're saying "easily." With a ginormous hand wave. You're asking for the software to act in a completely different way. It's not an unreasonable thing to ask for, but it's unreasonable to insist that it's "easy." As the guy who likes to tell us how checkbox options explode the QA space, it seems downright dishonest.
BTW, the sentence you coded said Git could "easily fill those roles", not "modifying Git to fill both those roles would be easy". I SUGGEST REMEDIAL 4TH GRADE READING LESSONS.
So, you're not complaining about the distributed nature of git there? In which case, it's easy and already done, to consider one repo the ground truth. I was keeping the context of the conversation in mind. If you'd like to retcon that out and withdraw some of your assertions, though, I'm cool with that.
-
I SUGGEST REMEDIAL 4TH GRADE READING LESSONS.
Is remembering what happened before in 5th grade now?
-
You're saying "easily." With a ginormous hand wave. You're asking for the software to act in a completely different way.
It's not a "completely different way." 95% of the Git codebase wouldn't have to be touched to make this change.
It's not an unreasonable thing to ask for, but it's unreasonable to insist that it's "easy."
I never did.
So, you're not complaining about the distributed nature of git there?
Yes, in that I'm complaining that it only works distributed and has no mode/ability to work in a centralized model.
In which case, it's easy and already done, to consider one repo the ground truth.
Right; but that doesn't help when you want to lock a file to prevent someone else from modifying it.
EDIT: wait a minute, you're in classical Boomzilla mode where if you don't agree with something I say, instead of just saying so, you just ask 573,342 pedantic clarifying questions until I say "fuck that" and leave. So fuck that.
-
I never did.
Riiiiiight.
It's not a "completely different way." 95% of the Git codebase wouldn't have to be touched to make this change.
How do you know this? I seriously doubt this. Big difference between doing stuff remotely vs locally. Lots more failure modes. Or maybe you wouldn't care that sometimes stuff just wouldn't work and didn't tell you in a reasonable way.
wait a minute, you're in classical Boomzilla mode where if you don't agree with something I say, instead of just saying so, you just ask 573,342 pedantic clarifying questions until I say "fuck that" and leave. So fuck that.
And now you're in classic blakeyrat mode where you get in a snit when the Socratic method uncovers your fuckwittery.
-
It doesn't have to be both simultaneously.
True, but then again, I can put in screws with my hammer (and pull them out with a claw hammer)...Or I can drive in nails with the butt of my screwdriver...
Why should they be different tools???
"Do one thing, Do it Well, and then move on".
-
"Do one thing, Do it Well, and then move on".
"Even if that one thing fails to cover the needs of the users."
-
"Even if that one thing fails to cover the needs of the users."
If there are multiple needs, then "one" thing is simply not the best way. I would strongly prefer to use multiple specialized tools, regardless of if I am developing software or building wood furniture - and the vast majority of people I have talked with feel the same way.
-
"Do one thing, Do it Well, and then move on".
None of the successful software programs in all of history have followed that stupid philosophy of dumb.
What's the "one thing" Microsoft Excel does well, for example? And yet it's one of the highest-selling and most-used programs ever.
-
I suppose you are writing this post from your "TDWTF" app, which only browses TDWTF posts? Not from a general purpose machine? And you have a separate computer that's optimized for writing code that you switch to when you want to code?
Some tasks can be generalized, some tasks can't. You don't have a different application for each kind of website you want to visit. In fact, trends have been towards abandoning rich clients and switching to web-driven interfaces for certain tasks. Sacrificing specificity for generality.
Similarly, if the task is "Hold the stuff you need to build a project", it's more user-friendly to have one single tool hold all the stuff, rather than have different tools to hold each kind of stuff you need. To their credit, git and hg and the like get you most of the way there by handling text, and being able to parallelize work helps you be more productive. But without diff and merge tools for other formats, you need to go back to a synchronous development model when modifying those files.
You already have pull and push as commands that need an external repo to be available, so it's not like git eschews the very notion of connecting to another. Distributed development needs that synchronizing steps happen regularly to function at all. Otherwise you just have disjointed repos that can't integrate. A locking mechanism would work just like pull and push do. They work when you are connected, they don't work if you aren't.
-
How do you know this? I seriously doubt this. Big difference between doing stuff remotely vs locally. Lots more failure modes. Or maybe you wouldn't care that sometimes stuff just wouldn't work and didn't tell you in a reasonable way.
It is the will of blakeyrat, so it must happen or else they're just dicks who don't care about their users. I do find it interesting that someone who refuses on principle to learn enough about git to do his job somehow magically knows (it must be magic, I'm sure he hasn't read any of the source code, otherwise he might figure out how to use it to do his job) that making git work the way he wants would be easy. But you seem to like arguing with him, so keep calm and carry on.
-
-
I do find it interesting that someone who refuses on principle to learn enough about git to do his job
Do you guys honestly think I don't do my job?
-
Do you guys honestly think I don't do my job?
We think you don't understand the things around you as well as you think you do.
-
That's not even close to what I asked.
-
Do you guys honestly think I don't do my job?
Honestly, I'm not sure. It's quite possible that you do in fact know enough about git to be able to put your code into source control, but that you prefer for some reason to pretend that you don't and complain about it here. If that's the case, we're used to it. I for one automatically read whatever you write with an implied
.
-
That's not even close to what I asked
What you asked isn't even close to what I think. A literate poster would have picked up on the implied no in my response.
-
We think you don't understand the things around you as well as you think you do.
or at least his online persona doesn't.
I'm reliably told he is a persona online source but... well.
I'm still not sure how real his online persona is. I seem to recall him saying that he doesn't have a persona here at all, but at the same time i seem to recall him saying that we don't get to see the real blakeyrat..... i'm sure at least one of those memories was put there by my shoulder aliens and to be honest i can't be bothered to try and discosearch to find out which one, if any, of my memories on the subject are correct.so in the interest of moving on i'll just lable that box with a big ol' question mark and call it close enough for today.
-
I seem to recall him saying that he doesn't have a persona here at all,
Cite that shit.
You have a history of making up shit and telling me I said it. A long, fucking irritating, history. You provide a link, or you shut the hell up.
i'm sure at least one of those memories was put there by my shoulder aliens and to be honest i can't be bothered to try and discosearch to find out which one, if any, of my memories on the subject are correct.
Hey if you know it's bullshit, why not stop spreading it around?
-
thank you.
Sources cited.
-
I'm reliably told he doesn't have a persona online source but... well.
That is also a lie.
-
then how about this. right here right now. are you running a persona here or are you true blue?
no messing about, no moving goal posts, no yelling about shoulder aliens. simple question, simple answer.
Is blakeyrat exactly you in real life or not?
-
I've said it's a persona about 50 times and it hasn't yet sunk into your tiny skull, I'm not sure why you think it would this time.
But if it does, I'd be grateful. Blakeyrat is not a person.
-
This post is deleted!
-
I've said it's a persona about 50 times and it hasn't yet sunk into your tiny skull, I'm not sure why you think it would this time.
I think it's mainly because i have a very hard time believing that blakey rat can be as incandesantly angry about the entire world, or at least very large parts of it, as he patently is in all the interactions i have participated and witnessed here on this forum without it also being true in real life.
I also find it hard to believe that you can take the stances that Blakeyrat does an stick to them as solidly and dependably as you do without that being your reactions in real life when you encounter similar situations.
I would expect to see cracks in a persona, ones that show you slipping out of character, however briefly, on occasion. I do not see these cracks, and it makes you as a persona less believable.
now I'm not trying to say that this means that you aren't a persona. I have no standing to say that at all. heck about half the time i'm pretending to be a fox! so there goes all the authority i never had on that matter right out the window.
why should you care at all what someone online thinks of you? why should it bother you if they cannot make up their mind how much of what you do and say is your nom de guerre and how much is actually the real you behind the mask?
from where i sit..... you shouldn't care, but if you do.... well the best i can say is.... sorry
-
What's the "one thing" Microsoft Excel does well, for example?
Nobody's said it yet, so... Spreadsheets!
-
Ok, this is bad.
@blakeyrat: Personal insults are over the line.
@accalia: Who blakey is irl is irrelevant.
-
-
SpreadSheets
Exactly, it is horrible to use as a Paint Program (though it has been done), Word Processor for large documents (also been done), and was never intended to be such.
And, yes, when writing code, I do use different tools for different types of software. Even if I am using a specific version of Visual Studio, I have different virtual machines with different configurations of tools (being a 32 bit process, VS really hates having them all loaded + there become conflicts).
-
VCS are for code.
Why? Do files other than code not have versions that need to be controlled? Could have fooled me.Until every remote operation takes 10 minutes of downloading/uploading/comparing stuff.
You might want to upgrade from your 2800 baud modem.Seriously, we don't have these problem. Sure, we have some things stored outside of VCS. But like I said above, binary != big.
What would be a good choice?
I don't know. I've seen something called git-annex. I think it's sort of you have some external collection of files, then pointers to those files where the pointers are versioned. I could be totally misremembering, or misrepresenting what it does.It is a subset of my normal comparison of CVCS vs. DVCS (regardless of actual tool). If you get benefit from having a central point (which typically implies having reliable connectivity) then go with a CVCS. I find this to be "the truth" for most business/corporate environments.
My attitude is as follows. Even for business/corporate environments, disconnected operations can be quite beneficial for people who travel and want to work from planes, airports, trains, etc.where there is either no internet or only expensive internet. But even beyond that, at least compared to Subversion, I think that Git and Hg offer a bunch of useful advantages that are mostly or entirely incidental to the fact they're distributed;git add --interactiveI think is amazing, as is the ability to amend and rebase commits that haven't hit a public branch. You could write some wrapper commands around Subversion to do all this (and I actually have written a script that acts as a limited, kinda crappy version ofgit add --patch; git commit), but by the time you put in that effort, why not just use Git?How do you know [you could add locking without changing 95% of the code base]? I seriously doubt this.
I've already explained how you could get a useful locking implementation in Git that is reasonably consistent with its overall operation1 [1,2, last part of 3]. I am nearly positive you could implement the locking portion entirely on top of the existing git commands (you could actually even do it as add-on scripts and hook up a [i]git lock[/i] command in the config file); the only thing that would have to change is the part that pulls a blob from the repository and puts it into the working copy: you'd want to have that check whether it should mark it read only.(Though I again reiterate that I'm not convinced an external system would be worse.)
1 Well, with the caveat that it would only work well with a "push" model where people have commit rights, and not for a pull-request or patch-based thing where human intervention is needed for commits to happen at a "definitive" repository. But that's still a lot of Git users.
-
I've already explained how you could get a useful locking implementation in Git that is reasonably consistent with its overall operation
To be clear, I was addressing using git where you don't do anything repo-wise locally, which is what I believe blakeyrat was talking about WRT not having to change 95% of the code base.
Why? Do files other than code not have versions that need to be controlled?
VCSes work best with text files where line based differencing makes sense. Good ones also allow you to plug in difference differencing mechanisms, and you can still use them with non-line based text files, but they won't work as well. IOW, they're designed to work with code.
Not that I'm arguing for some sort of purity. Just that you have to be willing to accept some trade offs when using them for stuff other than what they're built for.
-
I've already explained how you could get a useful locking implementation in Git that is reasonably consistent with its overall operation [1,2, last part of 3]. I am nearly positive you could implement the locking portion entirely on top of the existing git commands (you could actually even do it as add-on scripts and hook up a git lock command in the config file); the only thing that would have to change is the part that pulls a blob from the repository and puts it into the working copy: you'd want to have that check whether it should mark it read only.
The case for locking is entirely based around the starting position that some users are
gitsinconsiderate asses who don't try to coordinate their changes with anyone else. Unfortunately, any mechanism for distributing a list of current locks via the DVCS eventual-consistency transfer model will run into the problem that the asses won't synchronise very often. In fact, they might well only synchronise occasionally even when they want to make their changes available widely because they fail that way.
These same people will also pretty reliably decide that their changes are more important than yours and so force merges their way or (in a lockable system) preemptively lock everything just in case they want to make changes to it. Or maybe they just decide that simply saving the file to their local disk is enough and completely forget the whole “commit” business. (No, firing them isn't always an option. :sigh: I've collaborated with some annoying people in the past…)For example, you don't want the lock to apply across all branches at once — that would prevent someone from doing support on an old version while someone's developing a new one, or vice versa, which would be dumb — but then the lock becomes much more defeatable by simply branching. Branches are cheap in DVCSes. You could make the lock metadata attached to the file rather than a separate file, which would be good as that would then propagate across a branch, but that is a more intrusive change and has the possibility of transferring locks across from one branch to another when nobody intended for that to happen.
In a proper locking system, there is a single, authoritative location that you can query for the state of whether something is locked and to which you can make your requests to lock things to. (This is how you do locking. Period.) That totally doesn't work with “distributed” precisely because there isn't fundamentally a single location that is authoritative and which everyone can make requests to lock to…
It's possible to set things up to auto-synch on commit. That avoids many of the issues mentioned above, but doesn't prevent 'em. Simultaneous commits do happen for real in the wild. Non-maliciously. Locking everything is like putting a big honking mutex on everything in a parallel program “just in case”. It works (well, if you do it right) but it slows things down a lot. DVCSs use a different approach, perhaps more akin to software transactional memory…
-
My question about all this is "why are authors of binary-blob formats so loathe to provide a merge tool for their format?" Unless your design is bat-guano insane, it doesn't sound like too much to ask...
