Page 1 of 1
Subversion query... "label" a group of files as re
Posted: Thu Oct 12, 2006 4:52 am
by Chris Corbyn
We have a svn repository on our server. The Live (production) version of our project is nothing more than a SVN checkout of the repository inside the web root being used by clients. We just "svn update" this live version every time we reach a stage where the repository is stable enough to do so (bad?).
Lets say you have a really large project with thousands of files. You're making incremental changes to the respository and have the component you're working on ready to merge into the production version. However, the bit your colleague is working on is broken since he's still playing with it but he's committed the broken changes to the repository because they do have some use to us in development.
How can I merge the group of files (which could be scattered around) I've been working on back into the live version? I don't want to wait for my colleague to fix his code since it could be a few days away and the client wants my changes to be visible now.
I know I can manually "update" each file in the live version and it will work but that's a lot of effort. Is there some way to tell SVN that a particular group of files are related to each other even if they are not under the same directory? I'm thinking basically that if I could label the files I'm working on as being related to a specific component then I could just merge that particular component at it's latest revision back into the live version. Am I making sense? Anybody know what it is I'm trying to do?

Posted: Thu Oct 12, 2006 6:21 am
by feyd
Add a tag, update the server then rollback the "bad" file to the correct version?
Posted: Thu Oct 12, 2006 12:50 pm
by Ollie Saunders
[SlightlyOffTopic]I've got a subversion repository on google code. I have a working copy that I am developing and I want to commit it.
Unfortunately because I've moved so many folders and created new ones, and completely changed the contents of existing ones etc. subversion won't let me commit all of it. Anyway none of that matters right now.
Basically what I want to do is preserve my working copy and delete all the data in the repository on google code and do a commit so that the repository is up to date with my working copy.
How do I do this?[/SlightlyOffTopic]
Posted: Thu Oct 12, 2006 1:28 pm
by Chris Corbyn
Just guessing, I'm sure someone more knowledgable than me will know.
Start a fresh by doing:
Code: Select all
svn co http://repository/svn project
cd project
svn copy trunk branches/old_version
svn commit -m "Copying to make new branch"
svn delete trunk/*
svn commit -m "Emptying ALL trunk files out"
cp -r /path/to/new/project/* trunk/
svn add trunk/*
svn commit -m "Adding files for new version"
?
Posted: Thu Oct 12, 2006 6:12 pm
by Weirdan
We have a svn repository on our server. The Live (production) version of our project is nothing more than a SVN checkout of the repository inside the web root being used by clients. We just "svn update" this live version every time we reach a stage where the repository is stable enough to do so (bad?).
d11, I have similar setup, but I use separate branch for live version. I've been merging changes from trunk to live version manually, but if you're sure your HEAD revision is ready for production I guess you could do something like this:
Code: Select all
svn cp https://host/source/trunk/file1.php https://host/source/live/file1.php
svn cp https://host/source/trunk/templates/template1.php https://host/source/live/templates/template1.php
#... and so on
Of course you can further automate the process using, say, bash scripts or something...
Posted: Sat Oct 14, 2006 1:31 pm
by Ambush Commander
It sounds lke your codebase is large enough to warrant some restructuring. Here's how would do it:
branches/stable - Stable branch that is deployed on the website. The website itself is a checkout of this folder, when you want to update the site you just merge the changes to this branch and then svn up
trunk/ - Active development goes here, but changes made must not break the application. If they do, the committer is publically shamed and the repository rolled back to an earlier good version
branches/* - Active volatile development that is high risk and probably breaks the application. Once the code here is reasonably stable, it can be merged back into the trunk. The branch itself is an actual copy of the trunk code, svn merge will detect the changes to make merging them back easier
tags/* - If you want to be even more paranoid, forget about running things out of branches/stable: instead tag the stable branch and then switch the copy to the stable branch
branches/rel_*_* - After major feature releases, you may want to also maintain other branches for bugfixes, while the trunk chugs forward with features. This way, you can easily fix bugs without having to roll out features.
See When to Use Branches in
http://svn.collab.net/repos/svn/trunk/d ... tices.html for other reading
For now, you can probably do one of the stopgap solutions mentioned above. You may also want to consider custom svn properties (svn addprop).
Posted: Sat Oct 14, 2006 8:53 pm
by Chris Corbyn
Of course! So obvious now. I'll create a "stable" or "live" branch and we'll just use that in production

Somebody else suggested to me that "trunk" should only ever be stable but I don't get that... I thought trunk was always being worked on (well... usually). Besides, if I'm working on files in trunk and I need to leave the office to go home I'd like to think I can commit my (unstable) changes so that I can continue working from home.
Posted: Sat Oct 14, 2006 10:57 pm
by Ambush Commander
In that case I'd branch from working copy.