Version Control Questions Megathread (SVN / git / whatever else)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »

No Safe Word: Feb 26, 2005

git branch without any args is a no-op inside a git repo isn't it?

e: I see the same behavior with the same scenario, sadly I'm more used to the UI tools that I use now :shobon:

# ? Dec 19, 2014 21:10

Adbot: ADBOT LOVES YOU

# ? May 25, 2024 06:59

raminasi: Jan 25, 2005; a last drink with no ice

It does the same thing with git branch --list.

e:

code:

Me@COMPUTER ~/Documents/test (master)
$ git checkout testbranch
error: pathspec 'testbranch' did not match any file(s) known to git.

Me@COMPUTER ~/Documents/test (master)
$ git checkout master
error: pathspec 'master' did not match any file(s) known to git.

# ? Dec 19, 2014 21:12

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

GrumpyDoctor posted:

code:

Welcome to Git (version 1.8.3-preview20130601)


Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.

Me@COMPUTER ~
$ cd Documents/

Me@COMPUTER ~/Documents
$ mkdir test

Me@COMPUTER ~/Documents
$ cd test

Me@COMPUTER ~/Documents/test
$ git init
Initialized empty Git repository in c:/Users/Me/Documents/test/.git/

Me@COMPUTER ~/Documents/test (master)
$ git branch

Me@COMPUTER ~/Documents/test (master)
$ git checkout -b testbranch
Switched to a new branch 'testbranch'

Me@COMPUTER ~/Documents/test (testbranch)
$ git branch

Me@COMPUTER ~/Documents/test (testbranch)
$ git checkout -b master
Switched to a new branch 'master'

Me@COMPUTER ~/Documents/test (master)
$ git branch

Cody@AERIAL ~/Documents/test (master)
$

what in the goddamn

You've got a repo with no commits, it acts weird like that. If you add a file and make a commit things will work the way you expect them to. I'm running a newer build of msysgit than you are, 1.9.0 rather than 1.8.3. Not sure if the latest msysgit build (1.9.5 ) or the latest source release (2.2.1) still behave this way.

# ? Dec 19, 2014 21:31

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

I *expect* that more recent versions still do that though, as the semantics of branches in a tree with no nodes make no sense.

# ? Dec 19, 2014 21:35

raminasi: Jan 25, 2005; a last drink with no ice

Blotto Skorzany posted:

You've got a repo with no commits, it acts weird like that. If you add a file and make a commit things will work the way you expect them to. I'm running a newer build of msysgit than you are, 1.9.0 rather than 1.8.3. Not sure if the latest msysgit build (1.9.5 ) or the latest source release (2.2.1) still behave this way.

Huh, ok. I was actually trying to diagnose a different problem with VS2013 integration when I discovered this, but totally reinstalling msysgit and git extensions appears to have fixed that.

# ? Dec 19, 2014 21:41

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

To further illustrate Git's special "initial commit" state, when there are no commits in the tree:

code:

Welcome to Git (version 1.9.0-preview20140217)


Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest
$ git status
fatal: Not a git repository (or any of the parent directories): .git

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest
$ git init
Initialized empty Git repository in c:/Users/blotto.skorzany/Desktop/gittest/.git/


blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (master)
$ git status
On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (master)
$ git branch

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (master)
$ touch foo.txt

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (master)
$ git add foo.txt

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (master)
$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   foo.txt


blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (master)
$ git branch

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (master)
$ git checkout -b foo
Switched to a new branch 'foo'

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (foo)
$ git branch

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (foo)
$ git status
On branch foo

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   foo.txt


blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (foo)
$ git commit -m "beginning of repo"
[foo (root-commit) 16018b8] beginning of repo
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 foo.txt

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (foo)
$ git status
On branch foo
nothing to commit, working directory clean

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (foo)
$ git branch
* foo

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (foo)
$ git checkout -b bar
Switched to a new branch 'bar'

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (bar)
$ git branch
* bar
  foo

blotto.skorzany@STRENG7X321BSKO /C/Users/blotto.skorzany/Desktop/gittest (bar)
$

Note the "initial commit" state noted in the output of git-status when there is no root commit, and how committing that root commit is specially noted in git-commit.

# ? Dec 19, 2014 21:43

No Safe Word: Feb 26, 2005

Is anyone here using Team Explorer Everywhere for anything? I'm trying to get a Jenkins setup hitting our hosted TFS and it was running fine but now for some reason when I do a tf get I get random HTTP 203's on like half the files:

code:

Server returned HTTP status 203 for GET [url]https://app.vssps.visualstudio.com/_signin?[/url]
realm=xxxxxxxxxxxx.visualstudio.com&reply_to=https%3A%2F%2Fxxxxxxxxxxx.visualstudio.com
%2FDefaultCollection%2FVersionControl%2Fv1.0%2Fitem.ashx<snip a bunch of other stuff>

The weird part is that it's only like half the files and it's a different set of files each time. It's the same credentials I've always used and when I do the same command with the normal tf client things seem to be fine.

e: ignore those url tags, the forum is auto-inserting them :sweatdrop:

# ? Dec 19, 2014 21:47

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

If you want a technical explanation of git's behavior there, there's two concepts related to a "branch". The first is a "known branch" which is a pointer to an existing commit. These are stored in .git/refs. The second is the "current branch" which is stored in .git/HEAD.

When you do "git commit", it first looks up the current branch, which is in .git/HEAD, and then sees refs/heads/foo. If that file exists, it will update that ref to point to the new commit. If not, it will create it when committing.

If I'm on "foo", "git checkout -b bar" will first copy foo's ref to bar (cp .git/refs/heads/foo .git/refs/heads/bar), and then update .git/HEAD. If there is no ref by that name, it simply skips copying it.

"git branch" simply enumerates the known branches. So, after "git init", you have no known branches, and the current branch is "master". If you then do "git checkout -b foo", then there's no refs/heads/master, so it can't copy it, and it simply updates .git/HEAD to be "foo". If you then change again, all it will do is update .git/HEAD.

# ? Dec 19, 2014 22:20

wolffenstein: Aug 2, 2002; Pork Pro

So my dev shop has been only using Subversion to track the latest changes to code, and our production websites is just manually updated files. It's horrendous and leads to a lot of issues, so I'm trying to instate Git Flow as the standard methodology. However I'm still not sure how exactly to incorporate it into an already existing environment, especially when production is hardly in sync with the development branch. Any ideas or experiences to share?

# ? Dec 31, 2014 22:14

Marsol0: Jun 6, 2004; No avatar. I just saved you some load time. You're welcome.

wolffenstein posted:

So my dev shop has been only using Subversion to track the latest changes to code, and our production websites is just manually updated files. It's horrendous and leads to a lot of issues, so I'm trying to instate Git Flow as the standard methodology. However I'm still not sure how exactly to incorporate it into an already existing environment, especially when production is hardly in sync with the development branch. Any ideas or experiences to share?

I think the first thing to do is get production and development into sync; git won't fix that automatically as that seems to be a people/process thing. Once you get that handled then you can talk about changing source control. You might be able to get some "ammo" for moving if one of the pain points that caused the de-sync between production and development to be something subversion doesn't do well that git solves.

# ? Dec 31, 2014 22:38

Brain Candy: May 18, 2006

Marsol0 posted:

I think the first thing to do is get production and development into sync; git won't fix that automatically as that seems to be a people/process thing. Once you get that handled then you can talk about changing source control. You might be able to get some "ammo" for moving if one of the pain points that caused the de-sync between production and development to be something subversion doesn't do well that git solves.

This is all true, I'd like to just point out that git-svn exists and is super handy if you want to be that guy while everybody else is using svn.

# ? Jan 1, 2015 01:24

Less Fat Luke: May 23, 2003; Exciting Lemon

Also you may want to use GitHub Flow instead of Git flow - it's a bit more straightforward and has less complexities (which can help if a team is new to git):
http://scottchacon.com/2011/08/31/github-flow.html

# ? Jan 1, 2015 04:27

apseudonym: Feb 25, 2011

I'm pretty down on using Github for code review, it pushes people toward uploading fix commits to their feature branches instead of fixing commits. If you rewrite a commit to fix a reviewer comment(for a bug or a style nit or ...) the comments on the old commit just kind of disappear. I'm perplexed that people prefer the string of 'Add x' 'fix typo in x' 'fix bug in x' spam instead of a single fixed up 'add x'. It makes history and bisecting so much better.

I much prefer gerrit but open sourced on github because I wanted contributions and that's what most people use as well as my company having an official github and all that poo poo.

# ? Jan 1, 2015 05:34

Less Fat Luke: May 23, 2003; Exciting Lemon

Yeah gerrit seems pretty awesome. I've been bit a couple of times (well not me, but the group I work with!) where reviews will happen and then a rebase from master occurs that fucks something up. gerrit looks like it guards against things like that fairly well as you're signing off in a systematic way the final state of the commits.

# ? Jan 1, 2015 06:01

apseudonym: Feb 25, 2011

Less Fat Luke posted:

Yeah gerrit seems pretty awesome. I've been bit a couple of times (well not me, but the group I work with!) where reviews will happen and then a rebase from master occurs that fucks something up. gerrit looks like it guards against things like that fairly well as you're signing off in a systematic way the final state of the commits.

Its what I use for work(Android) and I've come to like it since it gives me the things I really want like tracking patch sets, comments on those sets, and letting me see the diffs between patch sets. Plus actually being able to see the state of code review at a glance is nice. UI isn't as polished look-wise at Github but I honestly dont give a poo poo about that.

# ? Jan 1, 2015 06:13

Paul MaudDib: May 3, 2006; TEAM NVIDIA:
FORUM POLICE

Is it possible to use auto-commit-on-build or similar settings in a team environment? I don't want a mile-long list of minor 1-line changes to get pushed to the team's master repo...

(Git)

Also, patience-diff is the best thing ever. It tends to do a better job aligning to content rather than on syntactic fluff like braces and keywords, which produces way better diffs.

Paul MaudDib fucked around with this message at 16:34 on Jan 5, 2015

# ? Jan 5, 2015 16:28

Gounads: Mar 13, 2013; Where am I?
How did I get here?

If you're working on your own branch, you can use rebase to squash a bunch together before merging it in.

# ? Jan 5, 2015 16:36

Space Whale: Nov 6, 2014

I made the mistake of mentioning git as part of the interview process, specifically that "why don't people ever use it for version control?" when just bullshitting after the "are you actually a programmer" quiz. Welp now the architect is moving everything over to git and since I don't work from 4 hours away I'm going to be explaining a little bit about it on Wednesday. Hooray. One other dev on the team has used it, but he similarly has only done branching and merging, not a single revert.

WTF?

Anyway, I found that http://onlywei.github.io/explain-git-with-d3/ git visualizer which is the bee's knees, and think it's a good way to explain the basics, that a commit reverting to a prior commit is itself a new commit, and that it's a bunch of connected nodes with pointers sliding around. Besides the commands that are shown there, is there anything else to touch on for an introduction?

Also, we're moving from TFS to git - should I tell people to use source tree, or the git tools in VS, or just the power shell thing, or what? I'd like to keep the team to one set of tools if possible, whatever it may be.

# ? Jan 12, 2015 19:48

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Space Whale posted:

Also, we're moving from TFS to git - should I tell people to use source tree, or the git tools in VS, or just the power shell thing, or what? I'd like to keep the team to one set of tools if possible, whatever it may be.

If they're already using TFS for more than just source control (work tracking/build/release) and they're on 2013, they can just make a team project that uses Git as the backing version control system and migrate the source code using git-tf and go wild.

If they're just using TFS for source control and want to dump it entirely, that's fine too.

I've been actually using Git from within VS a lot lately, the VS tools are okay for basic stuff, but not great. For most day to day stuff it's fine.

# ? Jan 12, 2015 20:07

Space Whale: Nov 6, 2014

Ithaqua posted:

If they're already using TFS for more than just source control (work tracking/build/release) and they're on 2013, they can just make a team project that uses Git as the backing version control system and migrate the source code using git-tf and go wild.

If they're just using TFS for source control and want to dump it entirely, that's fine too.

I've been actually using Git from within VS a lot lately, the VS tools are okay for basic stuff, but not great. For most day to day stuff it's fine.

I just had to give a crash course to a go-getter dev and the "I have a local repository, huh? When is it pushed? When can I share?" stuff just kept coming. It's really just DIFFERENT isn't it?

Wednesday will be fun.

# ? Jan 13, 2015 00:19

B-Nasty: May 25, 2005

Space Whale posted:

Also, we're moving from TFS to git - should I tell people to use source tree, or the git tools in VS, or just the power shell thing, or what? I'd like to keep the team to one set of tools if possible, whatever it may be.

I've been using, and enjoy, Git Extensions (https://code.google.com/p/gitextensions/) on Windows. It should allow people that aren't as familiar with Git to point-click their way to glory, and it looks much better than Source Tree. I couple that with the 3-way merger and diff'r from Perforce (P4Merge - which is a free component.)

Personally, I don't like my IDE and VCS to be integrated. It hides too much critical process, and VS is enough of a pig without yet another function to manage. I still use the CLI with PSGIT for some stuff, but for most beginners, they probably won't need the CL much. Even if they do, it'll be less of an uphill battle to explain how to do the CL functions after they've gone through the workflow a thousand times in a visual tool.

# ? Jan 13, 2015 03:58

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

If I want to fix multiple different issues upstream (on github) should I submit a separate pull request for each one? Or just 1 pull request with separate commits for each fix? Or do I create multiple branches in my fork and then 1 pull request for each ticket that I'm resolving?

I'm thinking it's supposed to be separate branches, separate pull requests. If that's the case, do I branch each one off whatever commit upstream is currently at? Or do I chain my branches?

fletcher fucked around with this message at 03:38 on Jan 14, 2015

# ? Jan 14, 2015 03:31

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

If they're unrelated issues, separate branches/PRs off the target upstream branch with only the changes relevant to each fix in each branch. A commit per change on a single branch makes it possible to review them independently, but not to merge one fix immediately, reject another, and spend a while refining a third.

# ? Jan 14, 2015 04:06

apseudonym: Feb 25, 2011

fletcher posted:

If I want to fix multiple different issues upstream (on github) should I submit a separate pull request for each one? Or just 1 pull request with separate commits for each fix? Or do I create multiple branches in my fork and then 1 pull request for each ticket that I'm resolving?

I'm thinking it's supposed to be separate branches, separate pull requests. If that's the case, do I branch each one off whatever commit upstream is currently at? Or do I chain my branches?

You should be branching off from ToT for each unrelated fix, avoid more than one fix per commit unless the issues are actually related.

Don't chain the branches since reviewers might want you to change things and you dont want to have to do rebases for all your follow up commits.

# ? Jan 14, 2015 04:57

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Cool, that makes sense. Thanks guys!

# ? Jan 14, 2015 19:31

Space Whale: Nov 6, 2014

I somehow managed to explain (baby, basic) git to complete newbies :shepface:

I hammered on "REVERT! Don't be afraid to use git as a vcs" and "don't, don't, DON'T reset". Was this a good idea?

# ? Jan 14, 2015 19:36

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Space Whale posted:

I somehow managed to explain (baby, basic) git to complete newbies

I hammered on "REVERT! Don't be afraid to use git as a vcs" and "don't, don't, DON'T reset". Was this a good idea?

I never revert and reset all the time but I also do all my work in private branches that get rebased/squashed/cherrypicked frequently. Logical histories are way more useful than accurate histories.

# ? Jan 14, 2015 22:48

raminasi: Jan 25, 2005; a last drink with no ice

B-Nasty posted:

I've been using, and enjoy, Git Extensions (https://code.google.com/p/gitextensions/) on Windows. It should allow people that aren't as familiar with Git to point-click their way to glory, and it looks much better than Source Tree. I couple that with the 3-way merger and diff'r from Perforce (P4Merge - which is a free component.)

Personally, I don't like my IDE and VCS to be integrated. It hides too much critical process, and VS is enough of a pig without yet another function to manage. I still use the CLI with PSGIT for some stuff, but for most beginners, they probably won't need the CL much. Even if they do, it'll be less of an uphill battle to explain how to do the CL functions after they've gone through the workflow a thousand times in a visual tool.

The problem with completely disconnecting git from VS is that it's easy to forget to save project and solution files before committing, and so external git can miss changes.

# ? Jan 15, 2015 01:16

Hughlander: May 11, 2005

Space Whale posted:

I somehow managed to explain (baby, basic) git to complete newbies

I hammered on "REVERT! Don't be afraid to use git as a vcs" and "don't, don't, DON'T reset". Was this a good idea?

If you pushed to a shared branch, revert. If you are on your own private branch you can be a loving Time Lord rewriting history left and right.

# ? Jan 15, 2015 01:50

ExcessBLarg!: Sep 1, 2001

Space Whale posted:

I hammered on "REVERT! Don't be afraid to use git as a vcs" and "don't, don't, DON'T reset". Was this a good idea?

If I see someone frequently making reverts I'd go beat on them. If they're doing a bunch of reverts without pushing, they need to learn rebase. If they're doing a bunch of reverts after pushing, and the pushes themselves aren't time sensitive, then they're pushing code upstream too quickly and not letting the changes fester long enough.

The latter assumes that the user is allow to force push on a private branch or they can push to a private repo though, unless local repos are really well backed up. It depends on the situation though.

But yes, logical history is a lot more useful than actual history.

# ? Jan 15, 2015 04:16

Fillerbunny: Jul 25, 2002; so confused.

I'd like to get some opinions on this situation:

We've got a database that's shared between several projects. For example, we have a website (and a series of white-labeled sites) that relies heavily on it, a couple desktop clients, and an API that targets 3rd parties.

We're storing the schema, including any stored procedure and function code from the database in a Git repo.

My project is one of the desktop clients, which has its own Git repo. In support of this client, we frequently need changes to or additional stored procedures. The procedures we rely on for this project are not shared between the other products.

Because we are contributing to two separate repositories, they are often disjointed and/or confusing.

What I want to do is get the db and client code in lockstep so they map 1:1 for features. In other words, when a stored procedure is written in support of a feature in the application, I would prefer those changes be reflected in a single repo/branch as it relates to the application feature.

I'm investigating git subtree as a possible solution to this, but I'm not clear on if it'll get me where I want to go, and I was hoping to hear some thoughts on it.

# ? Jan 15, 2015 15:46

ExcessBLarg!: Sep 1, 2001

If the stored procedures are really private and tied to the client, and really do change that often, I'd probably pull them out of the general schema and maintain them as a .sql file in the client repository, or possibly in its own submodule repository if you also want to check out just the procedures without pulling the entire client repo. That's the only way to ensure that the procedures are in lock step, commit-by-commit, with the client. Some folks might not like that suggestion though because it makes the client and database relationship "too cozy", but you're already there with a tightly coupled unstable API.

The alternative is to have a versioned API between the client and the procedures, to diligently denote version or feature updates, and to tag the commits that add them so that checking out the same tag in both repos yields commits that are at feature parity. The two respositories would remain separate, so there's always the chance they could fall out of sequence with each other, that's why diligence is needed.

The bazooka solution is to make the entire, general schema repository a submodule of the client repository, but that probably doesn't make sense for any other code organization purpose and will likely make folks not working on the client unhappy.

# ? Jan 15, 2015 16:56

Fillerbunny: Jul 25, 2002; so confused.

Thanks for that.

You're right that the client and database are too cozy, but it's the world we live in here, and we're way too far down that path to do anything about it. We've got enough logic in our data tier to make your toes curl.

I guess I should have mentioned that we're using Red Gate SQL Source Control and Microsoft SQL Server, with Git as the backend VCS. Our stored procedure changes are being made in SQL Server Management Studio, which then get applied to a database server run locally on a developer's machine. The changes are then tracked via SSC, and SSC scripts out those changes to individual .sql files in a particular folder, which are then committed to the Git repository.

I'm going to have to run some local experiments with subtrees, since it still feels like it might be the way to go, but does anyone happen to have a good resource about them? I've read the Atlassian blog a couple times in the past, and maybe it's time to look at it with a different perspective, but I'm looking for a different resource that'll explain the ideas and intent behind subtrees.

# ? Jan 15, 2015 20:49

No Safe Word: Feb 26, 2005

Okay, TFS question. Somewhere along the line with the same Collection we've had for a while now (using Visual Studio Online), new workspaces start checking files out as Read-only on the filesystem but existing workspaces do not. In general it's not a big problem because Visual Studio will do the checkout stuff for you behind the scenes which unsets the Read-Only bit on the filesystem, but I've incorporated some automated build stuff (updating version/dependencies in the .nuspec files for our stuff that buids as NuGet packages) which doesn't get that benefit so anybody who has had a new workspace in the past month or two now has to manually checkout the .nuspec files so they aren't read-only. Older users... no problem.

Did someone change a setting on the collection that may have caused this? Because I would like it not to be set to read-only on the filesystem on check-out...

# ? Jan 15, 2015 23:27

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

No Safe Word posted:

Okay, TFS question. Somewhere along the line with the same Collection we've had for a while now (using Visual Studio Online), new workspaces start checking files out as Read-only on the filesystem but existing workspaces do not. In general it's not a big problem because Visual Studio will do the checkout stuff for you behind the scenes which unsets the Read-Only bit on the filesystem, but I've incorporated some automated build stuff (updating version/dependencies in the .nuspec files for our stuff that buids as NuGet packages) which doesn't get that benefit so anybody who has had a new workspace in the past month or two now has to manually checkout the .nuspec files so they aren't read-only. Older users... no problem.

Did someone change a setting on the collection that may have caused this? Because I would like it not to be set to read-only on the filesystem on check-out...

It sounds like they're creating server workspaces instead of local workspaces. Are they by any chance using VS2010?

# ? Jan 16, 2015 00:57

No Safe Word: Feb 26, 2005

Ithaqua posted:

It sounds like they're creating server workspaces instead of local workspaces. Are they by any chance using VS2010?

Nah it's VS2013 and we haven't used 2010 in a loooooooooong time, long before this started. It may be the case that when we weren't having the problem it was with workspaces created in VS2012 but we've been on 2013 for quite some time. I know for sure I'm using a server workspace now and I do experience that issue.

...and switching to local made it go away. So did the default workspace go from Local to Server when VS2012 went to VS2013 maybe? Best I can tell, everyone followed the same procedure for workspace mapping/setup. For now I guess local is preferred, and based on this it seems like it is.

Thanks, Ithaqua.

# ? Jan 16, 2015 01:29

B-Nasty: May 25, 2005

GrumpyDoctor posted:

The problem with completely disconnecting git from VS is that it's easy to forget to save project and solution files before committing, and so external git can miss changes.

While true, and I admit to forgetting to save a csproj a couple times in my commits, I'm not sure that justifies integrating your VCS into IDE. A better way to solve it might be to perform a build before a commit (or at least before a push) so that you can ensure every revision will build/pass unit tests.

I guess I just like to keep separate functions separate. Probably why I refuse to use the database tooling in VS unless I'm dealing with some edmx monstrosity.

# ? Jan 17, 2015 01:25

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

VC++ doesn't save property sheets when you build (only on save all or when you close the project). It's pretty awesome.

# ? Jan 17, 2015 05:43

raminasi: Jan 25, 2005; a last drink with no ice

B-Nasty posted:

While true, and I admit to forgetting to save a csproj a couple times in my commits, I'm not sure that justifies integrating your VCS into IDE. A better way to solve it might be to perform a build before a commit (or at least before a push) so that you can ensure every revision will build/pass unit tests.

I guess I just like to keep separate functions separate. Probably why I refuse to use the database tooling in VS unless I'm dealing with some edmx monstrosity.

Do your thing, I guess, but I'm a pretty big fan of the "I" in "IDE".

# ? Jan 19, 2015 08:47

Adbot: ADBOT LOVES YOU

# ? May 25, 2024 06:59

duck monster: Dec 15, 2004

Company I've started working at uses SVN but gave me permission to use Mercurial for my stuff.

Just did a full merge from two SVN repos previously held to be unmergable using HG's SVN import with diffs in Kdiff in about a minute and my boss pretty much had his jaw hit the floor.

Guess Team HG got some new fans.

(My protip from migrating from SVN is to go with HG if you do a lot of windows stuff. Gits nice and all, but its got alien syntax if your used to SVN, imho, plus HG can quite happily cope with Git repos anyway [and vice verse])

duck monster fucked around with this message at 10:42 on Jan 20, 2015

# ? Jan 20, 2015 10:40

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »