StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
3731792
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2010-09-17T00:05:37.813
FavoriteCount
0
LastActivityDate
2010-09-17T00:05:37.813
LastEditDate
LastEditorUserId
0
OwnerUserId
79566
ParentId
3731631
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
<p>Subversion allows you to create a branch from an old snapshot, so you can branch off from r108 and commit your changes (r395-397) into that branch. However, you can't go back in and "insert" a commit into the tree's history. If you have administrator access to the server, you may be able to do some kind of kung fu with <code>svnadmin dump</code> to insert these changes into the tree at the appropriate time in the history, but it would throw off all of your revision numbers following that point (not to mention it would be a rather complicated procedure to go through). I can't imagine that process not causing all sorts of unexpected problems, especially with merge tracking.</p> <p>I tried to do something similar a while back, and I found that porting history from a non-organized system into a version control system was usually more trouble than it was worth. Instead, I took a code snapshot and made a clean break; everything before that snapshot was still available on the old server using the old system, and from that point onward all development would be done in the Subversion repository. We didn't lose any information and all of the history was still there, but it required developers to access the old server to get to it. It was annoying at first, but after a couple of months, the Subversion repo had developed enough of a history of its own that the builds from the old system became generally unused and were migrated out to an archive server. Since you've already set up your Subversion repo and included historical builds it's probably too late to make a clean split between legacy code and current code, but the idea still holds. You can add this new historical data to a server/fileshare that is hosting your historical builds and if anyone wants to see the most detailed history of a file beyond revision 200 (or whatever the rev number was when you stopped committing old builds and started doing active development), they can check the server.</p>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POSubversion: Retroactive Merging?
  singulars
  PostTypePostTypeId
  PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USbta
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POSubversion: Retroactive Merging?
  singulars
  PostTypePostTypeId
  PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
  singulars
  PostPostId
  PO
  UserUserId
  This table or related slice is empty.
  VoteTypeVoteTypeId
  VTUpMod
2. VO
  singulars
  PostPostId
  PO
  UserUserId
  This table or related slice is empty.
  VoteTypeVoteTypeId
  VTAcceptedByOriginator
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.