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)

Mine GO BOOM: Apr 18, 2002; If it isn't broken, fix it till it is.

LightI3ulb posted:

The easy part is figuring out whether or not the file exists, I just do a checkout on the file and parse the results. The hard part is trying to add the file to the svn when it does not exist. I need to find a way to be able to retrieve the .svn/entries file for the directory without checking out the entire directory.

If you are asking how to check in one file into a directory without checking everything out, just copy the file directly into the repository with svn copy local.file svn://server/repo/reports/ and it will add it in.

# ¿ Dec 21, 2009 18:53

Adbot: ADBOT LOVES YOU

# ¿ May 3, 2024 13:20

Mine GO BOOM: Apr 18, 2002; If it isn't broken, fix it till it is.

beuges posted:

We're going to do at least 90% of our dev in windows and the impression I've gotten from this thread is that the git clients for windows pretty much suck.

Give Mercurial a try then, as TortoiseHG is great in Windows. They even hit 1.0 yesterday.

# ¿ Mar 6, 2010 10:46

Mine GO BOOM: Apr 18, 2002; If it isn't broken, fix it till it is.

BizarroAzrael posted:

Is there an easy way to find out what version a repository was at at a given time on the command line? Say I wanted to update to the version for 4PM every day? Would I need to do an SVN log on the project and use a FIND command to get the last commit revision before that time? Or is there some existing function to do it?

svn up -r "{`date '+%Y-%m-%d 16:00:00'`}"

# ¿ Jun 9, 2010 18:01

Mine GO BOOM: Apr 18, 2002; If it isn't broken, fix it till it is.

BizarroAzrael posted:

Sorry, it says there's a syntax error, and I've not been able to find another example.

What shell are you using? This was something I just did real quick for bash, you should be able to look to see in almost any shell that you have some command to print a date, store that into a variable, and use that variable in svn up -r "{$VAR}"

# ¿ Jun 10, 2010 16:40

Mine GO BOOM: Apr 18, 2002; If it isn't broken, fix it till it is.

epswing posted:

Nothing's wrong with that plan, except at my new job there isn't a single linux machine in the building.

I've heard VMware Server has a nice price tag waiting for you that will fix this problem right up.

# ¿ Oct 7, 2010 02:50

Mine GO BOOM: Apr 18, 2002; If it isn't broken, fix it till it is.

We are using Mercurial with two shared repositories, a staging repo and a production repo. People push to staging for QA to test, then we pull those changesets to production. The problem is that each change gets individually scheduled for releases depending on management whims, so we need to cherry pick changes to pull from staging to production.

Right now we transplant the changes, but that leaves an ugly mess when we want to push/pull between production/staging repos. Anyone have a recommendation for a better way to have a staging repo that gets changes pushed to it whenever they are done, but won't go to production until management rolls some dice and comes up 12?

# ¿ Mar 24, 2011 05:00

Mine GO BOOM: Apr 18, 2002; If it isn't broken, fix it till it is.

bootleg robot posted:

I've written a decent sized application, and use subversion as version control. I have begun the process of placing the front end and the back end into their own separate assemblies. Does it make sense to maintain separate repositories for both?

If you have a nice API between the two, two separate repos are a good way to go. When you release changes that require both sides to be updated but isn't compatible with each other during the switchover, do a versioned API (call backend.com/v2/getdata instead of backend.com/v1/getdata) so you can release each part individually and not have to break things. Once both sides are stable with v2, in the backend you can delete the v1 of the API if it doesn't make sense to keep it.

Of course, I'm speaking from developing a project with 4-10 developers who work on both the frontend and backend at different times, so having separate repos makes a lot of sense since about 90% of our changes are either completely on one side or the other.

# ¿ May 4, 2012 06:19

Adbot: ADBOT LOVES YOU

# ¿ May 3, 2024 13:20

Mine GO BOOM: Apr 18, 2002; If it isn't broken, fix it till it is.

Jethro posted:

Assuming the changes are independent, is there a good way (or a better process) to merge the later changes from QA into Prod in such a way that later I can merge in the earlier changes?

I have been using transplant to pull in newer changes while an old change is still being tested. If you do this, you will end up with a complex mess if people don't correctly label their commits, or if they don't commit them to their original branch and then remerge their branch back into your test environment.

This works for my team because we have many small minor releases (transplant them to our Prod branch, push that) and then we have a bi-weekly high-impact release that pushes everything on Test out, giving time to the QA team for a semi-stable test environment.

If you (or anyone else) has better options, please let me know because sometimes it gets bad (ie: a high-impact release is delayed a few weeks, now have ~50 transplanted changes between Test -> Prod branches). We do our work similar to git flow and generally do most work in branches, which allows us to do internal code reviews and automated testing before it hits our Release branch that QA will then go over.

# ¿ Jun 3, 2012 23:05

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