Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Converting from CVS to Subversion?

Cliff posted more than 9 years ago | from the from-one-repository-to-another dept.

Programming 62

Bob Bobbinson asks: "I'm currently looking to convert my workplace's CVS repository over to Subversion. The main issue I'm having at the moment before I can commence a roll-out is how we are currently using tags, and sticky tags. The project is a website and we have two tags which are used to put changes from the main trunk live (internally, and externally). All development is committed to the main branch, and when we want a change to go live we move the two 'live' tags to that current version. The live servers are both sticky tagged to these tags, so when we run an update on these servers they will only update to the version that the 'live' tags refer to. Currently I haven't found a satisfactory way to replicate this in Subversion, as moving tags, and updating on separate servers seems to be quite kludgy i.e. need to remove current tagged version from tag, then copy from the main branch over to the tag, then update this on the live server. So I'm trying to look for an alternative way to implement this staggered releasing of code live, and maintaining the ability to see what versions of files constitute what is live. Any ideas?"

cancel ×

62 comments

Sorry! There are no comments related to the filter you selected.

fp for klerck (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12627332)

RIP brother
t4c misses you

CVS was designed for text files... (1, Offtopic)

Spy der Mann (805235) | more than 9 years ago | (#12627379)

IMHO you should stick to CVS. I mean, if it's not broken... why fix it? I'm pretty happy with CVS right now. And yes, I use it for an intranet.

Re:CVS was designed for text files... (3, Insightful)

EnronHaliburton2004 (815366) | more than 9 years ago | (#12627622)

I mean, if it's not broken... why fix it?

Because there are a ton of features in CVS which are broken? Moving directories, versioning metadata & permissions; etc.

I'm not really into SVN's versioning system either. I suppose I could get used to it, but I still like the flexibility of CVS tags. But there are many compelling reasons to move from CVS to SVN.

Re:CVS was designed for text files... (1)

endx7 (706884) | more than 9 years ago | (#12633604)

Oh yeah, SVN's "tagging" system was my biggest gripe too. The problem is SVN doesn't support tags at all. All it supports is cheap copies which are then "shown off" as tags. Branching is like this too, but makes more sense to be like that there.

I'll get used to it I suppose, but it bothers me slightly. I would have been fine if they just made it more transparent to the users, like giving a "svn tag" command to do the dirty work movement.

Also, I want websvn and viewcvs to show what tags are on a revision, but it sounds like more work to implement than it should be (especially because svn has no internal concept of tags!)

Re:CVS was designed for text files... (0)

Anonymous Coward | more than 9 years ago | (#12635049)

As someone who has had little experience with CVS, could you elaborate on what you can do with tags in CVS that are hard/impossible to do in subversion?

Re:CVS was designed for text files... (1)

ibennetch (521581) | more than 9 years ago | (#12676062)

Since no one else has responded I'll take a stab although I haven't actually *used* these tags (nor CVS, to be honest) but I think I 'get it'.

To my understanding, you can assign a tag to a specific revision and then always get that tag rather than have to worry about specific revision numbers. If you start working on a new revision to a file, the tag stays with the old working version until you're satisfied with a new revision and move your tag to the new revision. That way you can always pull the tag on to (as the poster is doing) main server (with a cron script) and never have to log on to the server to manually pull in changes.

It's easy with tags because you just tell the server to pull in anything that's tagged; with subversion there doesn't exist that sort of tag functionality so you have to deal with version numbers and that breaks the cron script because it relies on manual input.

Re:CVS was designed for text files... (0)

Anonymous Coward | more than 9 years ago | (#12628238)

"CVS was designed for text files..."

yeah.... and what?

What's that got to do with swithing to Subversion? Seriously, I want you to tell me.

Re:CVS was designed for text files... (1)

MemoryDragon (544441) | more than 9 years ago | (#12639246)

Actally CVS is broken by design, if you ever had a major refactoring session you would know what I mean.

WTF? (-1, Redundant)

brunson (91995) | more than 9 years ago | (#12627389)

Why is this on Ask Slashdot and not a subversion forum or mailing list?

Ya, (-1, Troll)

Anonymous Coward | more than 9 years ago | (#12627425)

Stick with CVS, not shitty broken subversion.

KDE (4, Informative)

JabberWokky (19442) | more than 9 years ago | (#12627429)

KDE just did a massive update including all tools and reporting software. It is the largest software repository running on Subversion. You might look into what they did.

--
Evan

Re:KDE (1)

smari (257143) | more than 9 years ago | (#12627551)

Version management systems, as a rule of the thumb, suck. SubVersion seems to suck quite a lot less than other sucky sucky systems like CVS. Now, this is not CVS to blame, nor is it RCS or any of those other systems.. it's the fact that this is something that hasn't been given all that much thought because of people who are used to using these systems, terrible or not, screaming "it's not broken, so don't fix it".

As for CVS, I use it on a few projects, with good results. Like I said, it's far from optimal, but I'm used to it, and I think I've only had about 20 or 30 corrupt repositories. I've got one project running on SubVersion, but it's got little experience yet.

KDE's upgrade went well as far as I know, but a lot of the branch tags got screwed up, vis-á-vis an e-mail from Stephan Kulow dated Thu, 31 Mar 2005 11:56:05 +0200. Check out the mailing list, or be a bastard and contact him. :P ... and sorry if somebody interpreted that as a troll. I should collect my thoughts about *why* version management systems suck and post them properly. :P

KDE (0, Redundant)

molnarcs (675885) | more than 9 years ago | (#12627435)

Perhaps you should ask the KDE folks (or browse their mailing list) - they just converted from CVS to subversion. Being such a large project and all, they must have encountered most of the issues one can in such a conversion.

Re:KDE (1)

molnarcs (675885) | more than 9 years ago | (#12632815)

For GOD's sake, check the dates before you moderate!

use the check-in numbers (4, Interesting)

maraist (68387) | more than 9 years ago | (#12627520)

First, each checkin should ideally be a legitimate build.. You shouldn't check in to the main branch things that are knowingly broken.

I assume you have a staging environment which would pull from the latest main-branch build.. It's easy to see what checkin version staging is using..

Once you have staging in an acceptible state ready for deployment, simply take the associated checkin-number (this SHOULD be a manual process) and post that to production.

In other words, ditch the remapping of tags as you used in CVS. This is an error prone process which destroys history.

In our development environment, we have a wiki that we (manually) update whenever we post things, and each deployment (to test, stage, production instanceX) has an associated svn checkin number.

If there is some memorable tag that we need, we svn cp a tag.. And obviously long-term modifications get their own branches.

While I'm not as happy with SVN's lack of relocatable tags, I do really like the idea that when using svn + fsfs as a backend, you have read-only back-versions. You can see everything associated with the checkin-number. CVS, on the other hand only lets you see the current state of the rcs files.. Sure there's a lot of history in there, but there is no associated "undo".. Yout have to use the cvs tools, and then you have to keep your fingers crossed that you're doing it right.

Re:use the check-in numbers (2, Insightful)

EnronHaliburton2004 (815366) | more than 9 years ago | (#12627601)

First, each checkin should ideally be a legitimate build.. You shouldn't check in to the main branch things that are knowingly broken.

Whoa there cowboy. There will be many cases where this isn't always practical.

For example, lets pretend you have a programmer working on the application code, and a designer working on the layout of a program. In this case, there is going to be a point where one person checks in their changes, which leaves the main branch in a broken state until the second person checks in their code.

You could solve this problem by creating an interim branch, and then checking that branch into main; but that adds alot of work to what is otherwise a simple, fast process.

Do you have any other suggestions for this situation. I'd be willing to bet this is the case for close to 50% of code checkins.

Re:use the check-in numbers (1)

maraist (68387) | more than 9 years ago | (#12627741)

First, each checkin should ideally be a legitimate build.. You shouldn't check in to the main branch things that are knowingly broken.

Whoa there cowboy. There will be many cases where this isn't always practical.


Notice I said "should". Obviously the alternative is to check in half-working code as your example implies.

IF, your test/staging environment is automatically pulling from the version-control back-end (via checkin-triggers or polling), then this is still a problem for you.. A human being has to determine when the checkin is valid. In the article's description, they were applying a "sticky" tag. Here, whatever process was applying that tag would be applying the checkin number.

If all checkins are assumed to be valid (backed by unit-tests), then the trigger could perform the auto-posting. This is often a good idea anyway to have some side validation deployment which on each checkin performs a full unit-test suite and flags the checkin as valid or not. In eXtreme Programming or Test-Driven-Design, I've seen the recommendation for the dual lava-lamps (red/green) being auto-triggered based on the most recent check-in.

Obviously some things are hard to unit tests (like web apps/ hardware-based applications), and some projects aren't willing to budget in unit testing. That's just a fact of life. But in these sub-optimal environments, there must be manual analysis.. ergo manual application of checkin numbers.

Re:use the check-in numbers (1)

pyrrhonist (701154) | more than 9 years ago | (#12630010)

For example, lets pretend you have a programmer working on the application code, and a designer working on the layout of a program. In this case, there is going to be a point where one person checks in their changes, which leaves the main branch in a broken state until the second person checks in their code.

Never do this. This is how shit happens. What happens is that you end up contaminating your main branch with a partial feature that you didn't test against its counterpart. Now you have a broken main branch that you can't cut a build off of. Furthermore, if the new feature contains a defect, you won't find out until the other developer introduces his changes to main, and by that time all hell has broken loose, QA is breathing down your neck, your paranoid boss is in your office, and the asshole in the other department is making fun of your group's incompetence (I am NOT bitter).

You could solve this problem by creating an interim branch, and then checking that branch into main; but that adds alot of work to what is otherwise a simple, fast process.

Yes, this is the correct thing to do! The interim branch makes it very easy to test the complete feature without contaminating the main branch or any other developer branches that need to merge features from main. If you have a good revision control system, this should be a relatively easy process to create a branch for this.

In our team, we use this feature so often that we created a script to do it for us. We can simply create any type of branch we need and then merge that branch into main after we are finished testing it. Because we are always merging, we never have collisions, we never need to lock any file, and we never contaminate the main line.

Re:use the check-in numbers (3, Informative)

dubl-u (51156) | more than 9 years ago | (#12630700)

Do you have any other suggestions for this situation. I'd be willing to bet this is the case for close to 50% of code checkins.

On your projects, perhaps. On mine, never. I use continuous integration tools like Anthill [urbancode.com] and Cruise Control [sourceforge.net] , and anytime a checkin breaks the build, the developers hear about it pronto. This is a little annoying to start, but once you get broken in it's fabulous: what's in CVS is always trustworthy, and if you see a problem you know it's your problem.

If you're just using CVS to pass around files, then you could just email the files around. If you keep the units of work small, clear, and discreet, this works fine.

Another option is to have areas in CVS for things that are half finished; the person to do the last bit of work moves things to their proper place.

With the designer/programmer split, one helpful approach is to make the last step connecting it to the rest of the app. So if it's a web app, you put up the new pages in a way where you can get to them only if you know the URLs. Then only when they're perfect do you add links from other pages.

You can also make features configurable, so that a feature is only visible if certain configuration options are set. This is especially valuable in environments where you have to roll out multiple related servers but need to bring everything live at the same time.

But my favorite approach is to get the necessary people together in one place. E.g., the programmer pairs with the designer, and you get things done in one go. Not only is it faster and more likely to work, but both sides learn a lot more about how the other guy works.

Re:use the check-in numbers (1)

nri (149893) | more than 9 years ago | (#12628611)

"First, each checkin should ideally be a legitimate build.. You shouldn't check in to the main branch things that are knowingly broken."

Yep it should at least compile without error. Doesn't need to be fuctional though. At our company it is a 'donut offence' to check in code that doesn't compile.

donut offense - means you gotta but the whole office floor donuts.

btw, if you buy Krispy Kremes then that is also a 'donut offence' as they are not allowed.

Re:use the check-in numbers (1)

brunson (91995) | more than 9 years ago | (#12628807)

You are an office of freaks! Krispy Kreme's are the best.

OT: find a real bakery (1)

bluGill (862) | more than 9 years ago | (#12630099)

Find yourself a real, old fashioned style, bakery and get some real donuts. Krispy Kreme's are good only in comparison to what you buy in the local big box grocery store. A real bakery much better.

Re:use the check-in numbers (1)

creimer (824291) | more than 9 years ago | (#12631296)

Krispy Kreme's are better suited to fatten up your co-workers while dulling their senses before running through the office with a loaded shotgun. Don't wait too long to start your rampage or they will keel over on their own from eating too many. ;)

Re:use the check-in numbers (1)

danbeck (5706) | more than 9 years ago | (#12629861)

I was listening until you said something stupid about Krispy Kreme.

Re:use the check-in numbers (0)

Anonymous Coward | more than 9 years ago | (#12631702)

"you gotta but the whole office floor donuts."

Do you mean cram doughnuts up everyone's ass? Sounds kinky.

Re:use the check-in numbers (1)

nri (149893) | more than 9 years ago | (#12632165)

yeah, fortunately spelling isn't a donut offence - provided its within a comment block :-)

btw to the other posters, I happen to like Krispy Kremes, but they are $1.80AUD each down here.

$1.80AUD (0)

Anonymous Coward | more than 9 years ago | (#12632441)

I happen to like Krispy Kremes, but they are $1.80AUD each down here.

Thats about ... hmmm .... 23 US cents, right?

Re:use the check-in numbers (1)

psykocrime (61037) | more than 9 years ago | (#12647549)

btw, if you buy Krispy Kremes then that is also a 'donut offence' as they are not allowed.

Then what's the point of buying donuts in the first place?

So YOU'RE THE ONE using CVS sticky tags! (0)

Anonymous Coward | more than 9 years ago | (#12627599)

Curse you! Sticky tags are the bane of CVS. I'm glad someone found a use for them, but I cannot imagine what.

Re:So YOU'RE THE ONE using CVS sticky tags! (0)

Anonymous Coward | more than 9 years ago | (#12627913)

You keep using that word. I do not think it means what you think it means.

Re:So YOU'RE THE ONE using CVS sticky tags! (0)

Anonymous Coward | more than 9 years ago | (#12629009)

Hey jerk-off - get a dictionary.

bane
Pronunciation: 'bAn
Function: noun
a source of harm or ruin : CURSE

Re:So YOU'RE THE ONE using CVS sticky tags! (0)

Anonymous Coward | more than 9 years ago | (#12631721)

He wasn't talking about "bane". He was talking about "glad". Or maybe "sticky". Yeah, "sticky" is funnier. He was talking about "sticky".

If I understand correctly, you want... (3, Informative)

danpat (119101) | more than 9 years ago | (#12627716)

svn co repos/trunk

svn commit

When /trunk is ready to go live:
svn rm repos/livetag
svn cp repos/trunk repos/livetag

Then, on the live servers:
svn update (where they have working copies of repos/livetag)

OR, you could do:
svn cp repos/trunk repos/tag-20050403
(i.e. create a unique tag for each release)

then, on the live machines do:
svn switch repos/tag-20050403

Either way should do the trick. And as other posters have pointed out, have you asked this question on the Subversion mailing list?

Re:If I understand correctly, you want... (2, Informative)

bigbadbob0 (726480) | more than 9 years ago | (#12631469)

I have a dev server that is always on trunk. When trunk is ready to push up I tag it. I switch to stage and do a svn switch to the new tag. I check for bugs on stage, address them on the tag and commit, merging up to trunk. When all is ready I do a final svn switch on the live site.

Re:If I understand correctly, you want... (1)

Tooky (15656) | more than 9 years ago | (#12631712)

Shouldn't you be exporting to the live site? Otherwise you'll be getting .svn folders with all your metadata available to the world?

Re:If I understand correctly, you want... (2, Interesting)

jbellis (142590) | more than 9 years ago | (#12633971)

It's not exactly hard to prevent apache etc to not serve .svn directories.

It's very worth it in terms of how much easier it is to sync with the latest bugfixes in your live branch.

Re:If I understand correctly, you want... (1)

Intron (870560) | more than 9 years ago | (#12638075)

You mean like this? [linuxcompatible.org]

Re:If I understand correctly, you want... (1)

bigbadbob0 (726480) | more than 9 years ago | (#12635372)

Apache has no problem hiding those from the world.

Clarification (1)

Yokaze (70883) | more than 9 years ago | (#12627780)

> i.e. need to remove current tagged version from tag, then copy from the main branch over to the tag, then update this on the live server

Do I understand you correctly? You prefer CVS over SVN because you can do a deployment with two (non-atomic) commandos (tag,update) instead with three (atomic) ones (remove,copy,update)?

I'm sure I'm missing something.

Otherwise, one could use a post-commit hook, which is triggered by a remove, which creates the tag from the branches.

Or one could check in the script itself, which pulls the newest version, and pull that automatically on the server side.
When there is a new revision, one changes the script to point to the new tag, which would also provide one with a better atomicity.

Or one checks in a configuration file for the script.

Re:Clarification (3, Funny)

brunson (91995) | more than 9 years ago | (#12628838)

You prefer CVS over SVN because you can do a deployment with two (non-atomic) commandos (tag,update) instead with three (atomic) ones (remove,copy,update)?

I prefer atomic commandos. GI Joe, the great american hero!

Just stop thinking in terms of "sticky" tags... (3, Interesting)

photon317 (208409) | more than 9 years ago | (#12627871)


In the subversion philosophy of doing things, ideally a tag shouldn't ever get changed. A tag should be pretty much a snapshot in time that stays as it is forever.

For instance, here's an example of branching/tagging the way subversion thinks of it (although you are free to twist it to other methods):

I have my main trunk, which lines in "trunk/..." in my repository. The trunk is at version 31666 right now. I decide that rev 31453 (the last good stable build from 2 days ago before I started mucking with a new feature) will be the branching point for my 1.0 stable branch. So I issue an "svn copy" command to copy rev 31453 of the turnk directory to a new place in the repository called "branches/1.x-stable". I tell the team that that branch is in feature freeze - debug it. They find a few bugs, which they commit to either the branches/1.x-stable tree, or the main trunk, and in either case they also copy their change to the other if it's applicable.

After a few weeks of debugging like this, I decide that at repository revision 31942, the "branches/1.x-stable" branch is stable enough to release the real 1.0. So I issue an "svn copy" command to copy rev 31942 of "branches/1.x-stable" to "tags/1.0". I never update this tree in tags/1.0 again. It essentially serves as a permanent record of what we released as 1.0, and a convenient spot to pull the 1.0 release from for packaging (or for comparison down the road).

After giving 1.0 to users, based on user feedback 3 new bugs were found in the 1.0 release. The coders fix these in the "branches/1.x-stable" tree, and reflect those changes back to the trunk if they're applicable (trunk may no longer have the affected code for all we know at this point). We decide that the 3 bugs were serious enough to warrant a 1.1 release to customers, so we make yet another "svn copy" off of "branches/1.x-stable", after the 3 fixes are in, as "tags/1.1", and release that copy as 1.1.

etc...etc...

To apply things to your situation (where you seem to essentially be using tagging but no branching, which is something you may wish to rethink down the line), essentially what you would do is every time you want to publish a "stable" copy internally or externally, you would just make a brand new tag. Instead of "updating" a tag named "internal" or "external" with your new code, you would create a new tag named "internal-1.1.2" or whatever you choose to version it as - but never change old tags, just make new ones.

Once you've done "svn copy" to make your new internal or external release tag, then you go to the actual webserver where you want to check it out, and in place of your previous "cvs update" on a checkout of a sticky "external" tag, you instead do an "svn switch" command from "tags/external-1.1.1" to "tags/external-1.1.2", which will alter the working copy as minimally as neccesary to switch you over to the new tag.

Re:Just stop thinking in terms of "sticky" tags... (2, Interesting)

Parity (12797) | more than 9 years ago | (#12628226)

I don't think that does what the poster wants to
do though.

The poster wants, I believe, to have a 'live'
release, so that some 'get the current "live"'
will always get the code considered to be
released. For example, by a cron-job doing
an update at 3:47 AM each night.

This kind of thing is not really amenable to doing an 'svn switch', which requires knowing whether or not things have changed and what the new version is called.

Perhaps the correct answer is 'write a more complex cron job that detects whether there is
a tag 'live-.*' where .* is a number greater
than the current version.'

Or perhaps the correct answer is to use a branch.

Or perhaps something else that a subversion user
would know.

(I'm not, and don't know, the original poster -
but having worked with CVS as web-site tracker
and CVS as compiled-code tracker... the poster
sounds like he's doing something much more like
the former... )

Re:Just stop thinking in terms of "sticky" tags... (2, Informative)

photon317 (208409) | more than 9 years ago | (#12628447)

If it has to be a cron job type thing that updates the internal and external websites to the "sticky" tags, then yeah I would recommend the cronjob pull the version from something else. One idea would be something like this:

myproj/trunk/[...]
myproj/tags/external-1.1/[.. .]
myproj/tags/external-1.2/[...]
myproj/externa l-release

Where the tags work as I outlined, and "myproj/external-release" is a text file which is manually updated to read "1.1" or "1.2" or whatever.

Then the cronjob on the production server essentially does

svn checkout svn://mysvnsvr/myproj/external-release /tmp/relnum
svn switch svn://mysvnsvr/myproj/tags/external-`cat /tmp/relnum` /web/root

Or what-have-you for the specifics.

Re:Just stop thinking in terms of "sticky" tags... (0)

Anonymous Coward | more than 9 years ago | (#12643614)

If it has to be a cron job type thing that updates the internal and external websites to the "sticky" tags, then yeah I would recommend the cronjob pull the version from something else. One idea would be something like this:

myproj/trunk/[...]
myproj/tags/external-1.1/[.. .]
myproj/tags/external-1.2/[...]
myproj/externa l-release

Where the tags work as I outlined, and "myproj/external-release" is a text file which is manually updated to read "1.1" or "1.2" or whatever.


You don't even need to do that. Just make external-release a copy of external-1.1 (or 1.2 or whatever). Copies are dirt cheap in subversion; they don't actually copy the files. So just do


svn cp svn://mysvnsvr/myproj/tags/external-1.x svn://mysvnsvr/myproj/external-release

(the above can be placed in a post-commit hook if you don't want to manually do it)

when you're ready to push out a new release. You production environment can be set ot always pull a working copy from myproj/external-release. Just put this in a cron script:

cd /path/to/production-env ; svn update

Personally, I think subversion would greatly benefit from a "tag" command even if it did nothing more than a copy to the /tags directory. At least it would shut up all those CVS whiners :)

Re:Just stop thinking in terms of "sticky" tags... (0)

Anonymous Coward | more than 9 years ago | (#12631768)

You know, manually wrapping the text in your post is annoying enough, but when you manually wrap most of the lines, but leave a couple to be automatically wrapped, so that they dangle out there like some obscene phallic symbol, that gets into the realm of really fucking annoying.

Why can't you just let people's browsers do the line wrapping for them? The technology to do this has existed for over 20 years. If people want to read your post all scrunched up, they can resize their browser windows to Callista Flockhart dimensions, and everyone's happy.

Re:Just stop thinking in terms of "sticky" tags... (0)

Anonymous Coward | more than 9 years ago | (#12638130)

Please just calm down and take your medication.

Re:Just stop thinking in terms of "sticky" tags... (0)

Anonymous Coward | more than 9 years ago | (#12631740)

"The trunk is at version 31666 right now."

Jesus Christ! How many times a day do you check stuff in? If your project was two years old, you would have to check in changes over 40 times/day, every day, including weekends and holidays, to get your version that high. Isn't that a bit excessive?

Re:Just stop thinking in terms of "sticky" tags... (0)

Anonymous Coward | more than 9 years ago | (#12669452)

dude, on large projects with many files and many people working on it, you can get that many updates in 6 months.

Maybe SVK? (1, Offtopic)

quake74 (466627) | more than 9 years ago | (#12627976)

I must admit I did not really understand your system setup. It looks to me that you could replace it with a distributed versioning system, like SVK [elixus.org] . Also probably of interest is this article [stosberg.com] . It talks about Darcs, but most of the fundamental concepts about distributed versioning systems are the same (across SVK, darcs, monotone, arch, etc).

You fucking moron (-1, Troll)

Anonymous Coward | more than 9 years ago | (#12628885)

"""
I must admit I did not really understand your system setup. It looks to me that you could replace it with a distributed versioning system, like SVK [elixus.org].
"""

Why the fuck do you post the comment if you didn't understand what the poster asks for?

+2, Informative. Fucking karma whore. Idiot. Bastard. Lamer.

use branches, OR revision numbers (4, Interesting)

Anonymous Coward | more than 9 years ago | (#12628317)

First of all, Subversion has no tags. They might call them "tags" but they are really just branches. I consider this a bit of a flaw but whatever.

What you need to do is either

1) remember the revision number of the repository which has the "good" code. Write it on a stick note or something. This is as close to a "tag" as you'll get. Then just tell your build process "revision #123124 is the one to use".

or

2) use a separate stable branch, and ONLY merge known working code to this branch.

I used to think #2 was almost impossible in Subversion (no tags!) but then I discovered svnmerge. See if you can find it, I can't find it anywhere in my FreeBSD or Gentoo installs and I had to download it separately. But it's a godsend! It's even *easier* than using floating tags in CVS to keep track of merge points.

Basically svnmerge will remember which revisions (specifically, which diffs between pairs of revisions) have been applied to a branch, by storing the information in properties. I have a big project with multiple long-lived branches (one for each client), and I could not figure out how to do this in Subversion until I discovered svnmerge.

In CVS it's easy ("easy" meaning, I can write down a set of instructions that can be mindlessly followed to get the right results), just create a floating tag that represents the last point you merged from. One on each branch for two-way merges.

svnmerge makes this easy in subversion too.

(It would be even *easier* if Subversion tracked changesets instead of tree revisions but that's a rant for another day.. Darcs is looking promising though).

Re:use branches, OR revision numbers (1)

endx7 (706884) | more than 9 years ago | (#12633842)

First of all, Subversion has no tags. They might call them "tags" but they are really just branches. I consider this a bit of a flaw but whatever.

I agree, except it doesn't really have branches either, just really cheap copies and a switch command. I don't consider branches a flaw though, although it seems like tags being this way is a flaw to me too.

Re:use branches, OR revision numbers (2, Insightful)

Bassman59 (519820) | more than 9 years ago | (#12646248)

First of all, Subversion has no tags. They might call them "tags" but they are really just branches. I consider this a bit of a flaw but whatever.

1) remember the revision number of the repository which has the "good" code. Write it on a stick note or something. This is as close to a "tag" as you'll get. Then just tell your build process "revision #123124 is the one to use".

Ah, you don't get it -- to "tag" a release, you simply copy the head to your "tag." You can even mark the tag as read-only. Then you tell the production people to check out the tag. It's really simple.

svn:externals? (2, Informative)

malachid69 (306291) | more than 9 years ago | (#12628411)

Pardon me if this is completely off-base, but I only switched from CVS to Subversion about a week ago.

Couldn't you use svn:externals to do what you want? I mean, couldn't you have a 'live' project or something that simply listed whatever tag you wanted in your externals? Then, whenever you get the 'live' site, it would get whichever tag was currently referenced?

Instructions are at http://svnbook.red-bean.com/en/1.0/ch07s03.html [red-bean.com]

Subversion software -vs philosphy (4, Informative)

MobyDisk (75490) | more than 9 years ago | (#12629646)

Subversion doesn't support "tagging" like you call it. There are constant of posts the subversion mailing lists about this. 90% of them are ignored, and a few get responses. They prefer to use their branching concept.

This is a case where the authors of Subversion are trying to force their philosphy of how to use version control on the users. I understand that: It is nice when your users are using the software the way that yoy think is best. But that isn't always possible, and they've removed a feature that is common to 90% of all source control systems.

That makes it very hard to migrate to Subversion. There are many build tools, developer's brains, and business procedures that depend on the concept of tagging. Their arguments against it only take into account one side of things. And unfortunately, it has become more of a holy war with the developers ignoring legitimate reasons to support it rather than address them. I really hope this changes, or I fear Subversion will never gain the "critical mass" that CVS has.

With that complaint out of the way, you can somewhat do what you want with two ways. One is to use a branch instead of a tag, and have some way to identify which branch is the "live" branch. A text file. A custom field on one of the files. A rule like "live-###" where you take the largest number. These are your best bet.

If you use a system where you have a large hierarchy, and you cannot deal with all those branches showing up on the tree (it can get really messy) than you can delete old branches, or move them elsewhere. If that's not possible, you are SOL, and Subversion won't work for you.

Re:Subversion software -vs philosphy (1)

sploxx (622853) | more than 9 years ago | (#12640667)

What is wrong with doing a svn cp to tag a version?
It works, it is nice, there is less to learn and it is as powerful as a CVS tag.

use switch (1)

Great_Jehovah (3984) | more than 9 years ago | (#12638392)

i.e. svn switch /path/to/new/tag

You'll have to change your setup to get the name of the new tag but it can't be that hard to write a script to do this (e.g. take the last entry from a run of svn ls /path/to/tagdir)

svn is not completely feature-for-feature with CVS. In most cases missing CVS features are replaced with one or more better designed features.

IMO the only seriour problem with subversion is training all the users not to fuck up their working copies by renaming and deleting things behind svn's back.

Re:use switch (0)

Anonymous Coward | more than 9 years ago | (#12668815)

Assuming they don't muck up the .svn directories (which are hidden, so that should be harder than doing the same in CVS), it's a lot easier to recover from a mucked-up working copy--just svn revert, with maybe some judicious studying of the svn status output. Works great, and never need muck-up the repository.

CVS "modules" file? (1)

smcdow (114828) | more than 9 years ago | (#12639324)

I've been looking around for documentation on this topic, but I haven't had much luck. How do you do the the equivalent of the CVS "modules" file using subversion?

See http://www.cvshome.org/docs/manual/cvs-1.11.20/cvs _18.html#SEC159 [cvshome.org] for details

For instance we share code across products via the CVS "modules" file:

p1 m1 &m100 &m101 &m102 &m103 &m104
p2 m2 &m100 &m101 &m102 &m103 &m104
p3 m3 &m100 &m101 &m102 &m103 &m104
How could we do this using subversion?

This is about the only real thing holding us back from switching over.

Re:CVS "modules" file? (0)

Anonymous Coward | more than 9 years ago | (#12652354)

it looks like modules were an addon to get-around the cvs-issue that you cannot rename directories without losing their history - easily. depending upon WHY you are using modules, you will surely find equivalent svn commands/processes to use.

as someone else has suggested, try to explain in more detail what you accomplish with your modules-names on an svn-mailing-list - and you will prolly get an answer about how to equivalently accomplish the same thing in subversion.

to first order, id guess your projects could be regular named branches. your modules could be either branches, or just code stuffed in the main trunk, and any tricky-stuff could be handled with hooks and tags as needed. remember, you can also add unique metadata/properties too...

good luck.

Re:CVS "modules" file? (1)

aled (228417) | more than 9 years ago | (#12659984)

Perhaps you can use subversion external's [red-bean.com] ?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>