|
sure, i could use apt or some poo poo and maintain config files that point at all the different lib versions ... ooorrrrr ... I could save a bunch f time and effort and just loving use svn and not be a huge weirdo about it just because someone told me once that you shouldn't check in binaries to version control
|
#
?
Mar 16, 2013 22:13
|
|
|
|
| # ? Jun 4, 2024 15:21 |
|
|
rotor posted:sure, i could use apt or some poo poo and maintain config files that point at all the different lib versions ... ooorrrrr ... I could save a bunch f time and effort and just loving use svn and not be a huge weirdo about it just because someone told me once that you shouldn't check in binaries to version control I'd rather not drive the people who have to deploy my half baked pile of poo poo random binaries from around the internet to any more drink than they'd naturally consume.
|
|
#
?
Mar 16, 2013 22:15
|
|
|
Zombywuf posted:I'd rather not drive the people who have to deploy my half baked pile of poo poo random binaries from around the internet to any more drink than they'd naturally consume. ?? look, here's how it works version 2.0 of my poo poo depends on v1.2 of Third Party Library X. I check this lib into source control under /thirdparty/libs. When I release version 2.0, i tag the entire tree as VERSION_2_0_RELEASED, and release the stuff to my customers. They have one copy of Library X, namely 1.2, the one that works with this release. now, later, Library X moves versions and features. version 3.0 of my poo poo now depends on Library X version 1.3, so copy the new version into /thirdparty/libs and check it in. When I release version 3.0, I tag the tree as VERSION_3_0_RELEASED and send it to my customers, who also now have one copy of Library X, namely 1.3, the one that works with this release. the tree should be self-contained. If you have dependencies on external things, they should be in the tree if reasonably possible.
|
|
#
?
Mar 16, 2013 22:34
|
|
|
i just wanna smash git push origin master not do all tha tshit
|
|
#
?
Mar 16, 2013 22:41
|
|
|
rotor posted:I check this lib into source control under /thirdparty/libs. sorry you lost me there only time you should commit a lib to a repo is if it's a browser library because no one's made a decent package manager for client-side js libs yet other than that it should all be handled by your gemfile/requirements.txt/package.json/some_java_bullshit.xml
|
|
#
?
Mar 16, 2013 22:43
|
|
|
abraham linksys posted:sorry you lost me there you know, just read the last 10 pages, i don't think we need this reset to the start of the argument with a new person
|
|
#
?
Mar 16, 2013 22:51
|
|
|
abraham linksys posted:sorry you lost me there please, lets try to keep these forums troll-free
|
|
#
?
Mar 16, 2013 23:02
|
|
|
i'm working on a project that has both a requirements.txt and a package.json because it's a tornado-based python app that uses grunt to compile static assets 
|
|
#
?
Mar 16, 2013 23:03
|
|
|
rotor posted:They have one copy of Library X lol, you really do hate users.
|
|
#
?
Mar 16, 2013 23:30
|
|
|
Zombywuf posted:lol, you really do hate users. yeah but I shield them from dependency hell by static linking anyway
|
|
#
?
Mar 17, 2013 00:42
|
|
|
abraham linksys posted:sorry you lost me there this is nasty, but at least js libs are never derived artifacts. you are not compiling the third library and then stuffing the artifact in source control. the java analogue would be including all of the source of the third party library with your app. it is inelegant, but you are not losing/mangling any information edit: if you are committing minified js to vcs, yeah you are worse than hitler etc etc Notorious b.s.d. fucked around with this message at 04:51 on Mar 17, 2013 |
|
#
?
Mar 17, 2013 04:00
|
|
|
Cybernetic Vermin posted:yeah, most of those requests are complex poo poo to solve problems that are created by not having everything necessary in the same version history, and rather than spending 2 seconds to push what is needed into svn i should have started a multi-decade process changing the ways a fortune 50 company works in all projects. i am starting to really want to know what mess you are picturing here. let us imagine this setup: let me apply your argument to source control itself: "why on earth should i have a complex tool like subversion, with an even more complicated server-side component? i can just re-name files every time i make a change, and the version history will be obvious from the pattern. how stupid do you have to be to fail to recognize that "libButtPucker.c.v2.0" is newer than "libButtPucker.c.v1.99" ? no one would ever mix that poo poo up"
|
|
#
?
Mar 17, 2013 04:07
|
|
|
to put it plainly, we build tools to remove human error from the process. putting your derived artifacts in source control may work some of the time, but it has no forcing factors to prevent fuckups. if we want, we can implement literally any protocol as a procedure and just rely on staff to never, ever gently caress up. version control itself exists to prevent a large class of fuckups. artifact repositories are the next logical step, to prevent another class of fuckups so here are the most obvious problems with derived artifacts in vcs: there's no metadata to link the artifact to the source that produced it, and there's nothing to prevent people from inserting new revisions of the artifact in the branch. lastly, and most importantly, there is no way for projects to declare their dependencies, short of complex svn mv/branch operations to include copies of derived artifacts. it's a clusterfuck
|
|
#
?
Mar 17, 2013 04:07
|
|
|
Notorious b.s.d. posted:
a) I don't have the source b) ok, but this doesn't really happen c) oh no! branches and tags!
|
|
#
?
Mar 17, 2013 05:26
|
|
|
uG posted:Just use 2 versioning systems then version those 2 systems together on a 3rd versioning system and then you can both be wrong i put my .git under svn
|
|
#
?
Mar 17, 2013 05:35
|
|
|
abraham linksys posted:i'm working on a project that has both a requirements.txt and a package.json because it's a tornado-based python app that uses grunt to compile static assets I will give you a gun with a single bullet in it and a butter knife. After a week you are going to be real upset you used the gun to shoot your computer. Luckily you still have your butter knife to kill yourself.
|
|
#
?
Mar 17, 2013 06:19
|
|
|
yaoi prophet posted:i put my .git under svn
|
|
#
?
Mar 17, 2013 07:39
|
|
|
Gazpacho posted:somewhere there is a company that does this it means that even if you have a bad rebase you can just restore from backup!!
|
|
#
?
Mar 17, 2013 07:44
|
|
|
Mr Dog posted:if you're using triggers you've made some seriously poor choices in ur life trigger dicipline
|
|
#
?
Mar 17, 2013 08:01
|
|
|
~• trigger warning •~
|
|
#
?
Mar 17, 2013 08:10
|
|
|
Notorious b.s.d. posted:to put it plainly, we build tools to remove human error from the process. this glosses over a few important details. it isn't all human error these tools are built to tackle, it is random human error that is of interest here. and it isn't that we want all the random human error removed, specifically. rather, we want that random error converted into systematic error whenever it occurs, because we already have the tools we need for identifying and correcting systematic errors Notorious b.s.d. posted:putting your derived artifacts in source control may work some of the time, but it has no forcing factors to prevent fuckups. if we want, we can implement literally any protocol as a procedure and just rely on staff to never, ever gently caress up. version control itself exists to prevent a large class of fuckups. artifact repositories are the next logical step, to prevent another class of fuckups this is all well and good. but if these two repositories don't present a unified façade, don't understand and talk to each other, if they need a human to act as a mediator between them... that's a big source of random human error that this combination system adds compared to a single system
|
|
#
?
Mar 17, 2013 09:08
|
|
|
examples of systematic human errors in the same context: - using different new line-characters than the codebase, or tabs instead of spaces - writing a c++ function using coding conventions from c - thinking array indexing starts at 1, then allocating an extra array element to workaround the inevitable off-by-one error - leaking memory by not taking ownership of a given resource
|
|
#
?
Mar 17, 2013 09:34
|
|
|
Notorious b.s.d. posted:so here are the most obvious problems with derived artifacts in vcs: there's no metadata to link the artifact to the source that produced it, and there's nothing to prevent people from inserting new revisions of the artifact in the branch. lastly, and most importantly, there is no way for projects to declare their dependencies, short of complex svn mv/branch operations to include copies of derived artifacts. it's a clusterfuck for someone who goes off about people not reading posts properly you sure live in your own little fantasy world a lot, this is nothing like my case. i have not used the term "derived artifact" once in this whole discussion, and have made clear several time that i am not putting stuff built from source i control into version control. the bit about declaring dependencies is deeply retarded, the dependencies are the things in the repository, i declare that the system depends on javelin-appia-3.0.1.jar by virtue of that jar being in that revision. the dependencies being managed by svn tagging/branching is an advantage either way, you have said nothing new, remotely interesting, or even funny since the start. i'll quit trying to explain to you now, to spare the world this sperg poo poo discussion about what is philosophically pure svn use, and how successful projects may actually ruin the world (being big finance this might actually be true, but certainly not because of svn use patterns). i thank shaggar for the lesson on maven/nexus, which sounds like good stuff for broader project dependencies, but if it isn't already set up there is no reason for people to fear putting documentation/testing data/training material/planning documents or just about anything into svn if it needs to be in sync with the project, and it in any way helps you day to day.
|
|
#
?
Mar 17, 2013 10:59
|
|
|
Cybernetic Vermin posted:for someone who goes off about people not reading posts properly you sure live in your own little fantasy world a lot, this is nothing like my case. i have not used the term "derived artifact" once in this whole discussion, and have made clear several time that i am not putting stuff built from source i control into version control. the bit about declaring dependencies is deeply retarded, the dependencies are the things in the repository, i declare that the system depends on javelin-appia-3.0.1.jar by virtue of that jar being in that revision. the dependencies being managed by svn tagging/branching is an advantage So when you said that your deployment environment was stuck on some old version of javelin-appia which was why you were shoving jars in your repo what you meant was "I've made the repo so hosed up with trying to fix deployment problems in source control I don't even know what's going on anymore?"
|
|
#
?
Mar 17, 2013 13:22
|
|
|
Zombywuf posted:So when you said that your deployment environment was stuck on some old version of javelin-appia which was why you were shoving jars in your repo what you meant was "I've made the repo so hosed up with trying to fix deployment problems in source control I don't even know what's going on anymore?" just about every post you make is incomprehensible. what do you mean deployment environment being stuck on some old version of appia? they are as part of the deployment package getting the exact version with which the software was developed, tested, and certified. they are meant to get that version of that library, it is critically important that they do. you keep repeating your idiotic misunderstanding about this being about release management as well, you are being ignored because it makes no sense, packages are built, overly complex release managements procedures are involved, this has no loving bearing on the day that we need to drop back to version 1.2.0 for some reason to debug/develop/backport something, and at that point we want to restore the situation under which it worked without having to download and dissect the release by hand
|
|
#
?
Mar 17, 2013 13:41
|
|
|
Cybernetic Vermin posted:just about every post you make is incomprehensible. what do you mean deployment environment being stuck on some old version of appia? they are as part of the deployment package getting the exact version with which the software was developed, tested, and certified. they are meant to get that version of that library, it is critically important that they do. you keep repeating your idiotic misunderstanding about this being about release management as well, you are being ignored because it makes no sense, packages are built, overly complex release managements procedures are involved, this has no loving bearing on the day that we need to drop back to version 1.2.0 for some reason to debug/develop/backport something, and at that point we want to restore the situation under which it worked without having to download and dissect the release by hand Seriously, you seem to be suffering the after effects of some serious stress. I suspect the stress is due to working in an environment where you were managing applications end-to-end out of your source control repo while not having the power to apply the obvious solution to problems like this: quote:program trading desk is still running version 2 of the client whereas sales trading has moved to version 3, we need to backport a feature from version 3 to version 2 for them, in the process the documentation and testing procedures should be updated accordingly. (the obvious solution is: I'm only supporting one version, sales and program can fight it out between themselves)
|
|
#
?
Mar 17, 2013 13:48
|
|
|
Zombywuf posted:Seriously, you seem to be suffering the after effects of some serious stress. seriously, you are being stupid here, and your suggestion is retarded, i got well paid and rewarded to provide this service, had fun in the process, and the desks appreciated the results. you 100% seriously would be clearing out your desk five minutes after refusing to provide the software requested due to sperg "principles". quitting this end of the discussion now as well, this thread is way overdue to go back to talking about prolog or something
|
|
#
?
Mar 17, 2013 13:58
|
|
|
Notorious b.s.d. posted:this is nasty, but at least js libs are never derived artifacts. you are not compiling the third library and then stuffing the artifact in source control. minimized js is hitler full stop just gzip it, god
|
|
#
?
Mar 17, 2013 13:59
|
|
|
Cybernetic Vermin posted:seriously, you are being stupid here, and your suggestion is retarded, i got well paid and rewarded to provide this service, had fun in the process, and the desks appreciated the results. you 100% seriously would be clearing out your desk five minutes after refusing to provide the software requested due to sperg "principles". quitting this end of the discussion now as well, this thread is way overdue to go back to talking about prolog or something There's a reason I avoid working at places that won't respect my opinion. Something to do with not being a doormat.
|
|
#
?
Mar 17, 2013 14:18
|
|
|
Zombywuf posted:There's a reason I avoid working at places that won't respect my opinion. Something to do with dunning-kruger
|
|
#
?
Mar 17, 2013 14:36
|
|
|
Zombywuf posted:There's a reason I avoid working at places that won't respect my opinion. Something to do with not being a doormat. i'm agnostic regarding what kind of dumb poo poo people check into their repos, but this is true regardless
|
|
#
?
Mar 17, 2013 15:09
|
|
|
you can use github to host code and sourceforge for binaries, apparently thats pretty common, talking to the sourceforge dudes. also, sourceforge is still around.
|
|
#
?
Mar 17, 2013 16:00
|
|
|
I don't know if thats good i've never hosted a binary
|
|
#
?
Mar 17, 2013 16:02
|
|
|
Ronald Raiden posted:I don't know if thats good i've never hosted a binary
|
|
#
?
Mar 17, 2013 16:21
|
|
|
source forge is home to such magical projects as kitchen garden aid 
|
|
#
?
Mar 17, 2013 16:42
|
|
|
horse mans posted:source forge is home to such magical projects as i'm the drugs no, the other drugs
|
|
#
?
Mar 17, 2013 16:46
|
|
|
im the 
|
|
#
?
Mar 17, 2013 18:50
|
|
|
Zombywuf posted:There's a reason I avoid working at places that won't respect my opinion. Something to do with not being a doormat. lolololololololololololololololol
|
|
#
?
Mar 17, 2013 19:34
|
|
|
zombywuf's work history: 1. doormat 2. dish cloth 3. poop janitor
|
|
#
?
Mar 17, 2013 19:35
|
|
|
|
| # ? Jun 4, 2024 15:21 |
|
|
this argument sucks lets have a new one. pick one of the below: * global state was hitler's best friend * type systems are too lax and thus we should have positive and negative numbers become different types * creative comedy option A * javascript and ruby, like best friends in a best friend place * your editor sucks which means you can't write computers * your beer sucks which means you can't write computers * creative comedy option B
|
|
#
?
Mar 17, 2013 19:45
|
|
