SVN question
-
This should be a simple question, but I'm not sure of the answer:
I have a working copy pointing to /trunk and a branch that originally came from trunk. I do an
svn merge --reintegrate
of the branch into the trunk working copy and commit.Is it safe to perform the same action again? Always? Assume one of the changes is a delete, which, if merged into the same branch twice, would provide a tree conflict as it tries to delete a file that's already gone.
-
I'm pretty sure that it is; as part of that it merges in the list of commits merged, so they are only ever merged once (like a normal merge does -- if you attempt to merge in a revision that has already been merged, nothing happens).OK, totally wrong.
-
"Once a --reintegrate merge is done from
branch to trunk, the branch is no longer usable for further
work. It's not able to correctly absorb new trunk changes,
nor can it be properly reintegrated to trunk again. For this
reason, if you want to keep working on your feature branch, we
recommend destroying it and then re-creating it from the
trunk[.]" See [url=http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate]The Book[/url].
-
Huh.
Okay. So what should I be doing instead?
-
It depends on the development pattern you're using. If it's a feature branch (branched only to work on a feature), then it shouldn't be merged until completed and all trunk changes have been merged into the branch. If it's any other type (stable, release, dev, etc.), then you just don't use --reintegrate.
-
It's a short-lived branch consisting of just items to be released this week, having passed testing, but I want to idiot-proof my methodology* so if I accidentally merge twice, it doesn't break. Leaving off "--reintegrate" will resolve that?
* Alright, that's an oversimplification. I actually want to automatically merge via CI, and also people are manually merging, and they won't have stopped doing so while I'm working on the automation. Still, same basic idea though.
-
I think it will mark it as merged in either case, and prevent re-merging. If you use --reintegrate, you must first patch in all changes to trunk since you made the branch and then never use the branch for anything again, and preferably delete it (it will still appear in history).
-
SVN simply can't do that. Once you reintegrate it to trunk, it's useless. until you merge --record-only trunk back to your branch, that is - but I don't recommend messing with mergeinfo if you don't know very well what you're doing
-
SVN simply can't do that
Can't do..which part exactly?
If I do a merge from a branch to trunk but I pick the specific revisions, which I've done before with Tortoise, then it greys out those revisions in the future, marking them as already merged. So at some level there's tracking of what changes have been merged. But I know there's some subtle differences between that and merging the whole branch, and subtle differences between merging the whole branch and reintegrating, and I'm not sure what they are, hence, my question.
Once you reintegrate it to trunk, it's useless
Yeah, the intent is not to keep using the branch so much as to prevent the scenario where my coworker merges and doesn't tell me, and then my CI system merges again, and all hell breaks loose with a tree conflict.
-
apparently there's something you can do for that in SVN
apparently it has to do with Forward Integrating and then Reverse Integrating.... or maybe the other way around?
i've never successfully done it myself but it can be done.
or so i'm told.
-
-
Damn.
-
Yeah, the intent is not to keep using the branch so much as to prevent the scenario where my coworker merges and doesn't tell me, and then my CI system merges again, and all hell breaks loose with a tree conflict.
Ropes should do the trick.
-
Yeah, I was hoping to be able to delegate some of the SVN crap I do every week, but I guess I'd better keep responsibility for it until it's automated. I don't trust my team to actually communicate well every week.
-
-
So at some level there's tracking of what changes have been merged
[trunk:root@centos trunk]# svn propget svn:mergeinfo -R | head -n5 . - /dev/branches/DEV4_V5.5.x:9476,9529,9565,9604 /dev/branches/DEV4_V8.1.x:33624,34972,35151,35191,35306 /embedded/dev4/branches/DEV4_V6.8.3R:37915 Kconfig - /dev/branches/DEV4_V8.1.x/Kconfig:34972,35151,35191,35306 /dev/branches/pjh/ndcondev-62/Kconfig:33573 ...
-
I'm fairly certain that this was one of the main driving forces behind Linus's choice to use BitKeeper for the Linux kernel.
-
I just went to Wikipedia and found out that git is newer than Half-Life 2. How the hell did we solve the problem of realtime facial animation rendering and physics-based gameplay before we solved the problem of storing multiple revisions of text files without a central server?
-
Simple - physics simulation is algorithmic problem, and version control is people problem.
-
You have a funny definition of "solved problems".
(Also, what @Gaska said.)
-
I just went to Wikipedia and found out that git is newer than Half-Life 2. How the hell did we solve the problem of realtime facial animation rendering and physics-based gameplay before we solved the problem of storing multiple revisions of text files without a central server?
With a hot tub time machine? It's not like git invented DVCS. It was Linus' solution to not being able to use what he had before (BitKeeper) which itself wasn't the actual pioneer:
-
I don't see a SunWorkShopTeamWareHub.
-
But if it's on the internet I wouldn't trust your connection to show it to you.
-
FWIW, as of Subversion 1.8 it is safe to reintegrate twice.
And as 1.8 was contemporaneous with the OP, the advice given here was bad.
-
@Greybeard said in SVN question:
FWIW, as of Subversion 1.8 it is safe to reintegrate twice.
And as 1.8 was contemporaneous with the OP, the advice given here was bad.
Timely advice!
-
@Greybeard So a bunch of people engaged in a bunch of SVN bashing and it turned out they didn't know what they're talking about and it actually works fine?
Gasp!
-
-
@masonwheeler said in SVN question:
@Greybeard So a bunch of people engaged in a bunch of SVN bashing and it turned out they didn't know what they're talking about and it actually works fine?
Gasp!
@masonwheeler
It does assume that the client is 1.8 while the server should be 1.5 or higher.It's not clear if this was true for Yami's environment (clients might be tied to crusty old IDE versions and the server might also have been ancient), though it would be hardly surprising if they actually could have supported it.
-
@dangeRuss said in SVN question:
@Yamikuronue said in SVN question:
Huh.
Okay. So what should I be doing instead?
Using Git.
Fun fact: this is an old thread, we're on git now.
-
@Yamikuronue I'm so sorry...
-
@masonwheeler For bumping the thread or the fact they're on Git now?
-
@JBert I'm not the one who bumped the thread.
-
...
-
@Yamikuronue said in SVN question:
@dangeRuss said in SVN question:
@Yamikuronue said in SVN question:
Huh.
Okay. So what should I be doing instead?
Using Git.
Fun fact: this is an old thread, we're on git now.
Did you go cold turkey or use git-svn first?
-
@dangeRuss Cold turkey. We're moving our repositories one at a time, taking the latest "get this shit into docker" branch as the new Master
-
@Yamikuronue I assume you're keeping backups of the old repos so you don't lose all the commit history?
-
@dangeRuss said in SVN question:
@Yamikuronue said in SVN question:
Huh.
Okay. So what should I be doing instead?
Using Git.
Nah. VSS. Suits the age of the thread at least.
-
@Yamikuronue git and docker?