[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Help setting up Subversion..

From: <Nick_Gianakas_at_sybari.com>
Date: 2005-01-12 18:12:18 CET

I haven't used Perforce, but we had a similar situation w/ VSS.
When first migrating to SVN from VSS, we kept both VC systems updated
simultaneously. To do this:

To setup SVN:
1. Checkout the SVN tree to your desired working area (initially empty)
2. Checkout VSS to the same dir.
3. "svn add" and "svn commit" all the files/dirs.
At this point, SVN is synched w/ VSS.
Whenever making changes to a file, simply commit to SVN and check-in to
VSS.
Fortunately, we didn't have to do this for long--svn proved itself almost
immediately.

You can probably use a post-commit hook in SVN to automatically perform
the commit/check-in to the other VC system.

Good luck.

Regards,
Nick G.

Joseph Silverman <yossie@laszlosystems.com>
01/12/2005 11:40 AM
 
        To: subversion <users@subversion.tigris.org>
        cc:
        Subject: Help setting up Subversion..

So, here's my situation:

a) I have a large perforce depot PART of which I want to "mirror" in a
subversion repository. I would then like to keep the repository up to
date with the depot.
b) I don't want to "mirror" everything in the depot (perforce), just
parts of it (the "public" parts) - these parts are spread around in it
(differentiated by filename and location in the directory structure),
not in a single directory tree.
c) Ideally, I would like to initially import all the files in a single
"commit" so that the version number in subversion is 1 for these.

I have (perforce) synced down the whole depot into a local copy (we
have this for other purposes) and want to use it as my "working copy"
for subversion.

Initially, when I try to simply add a bunch of files out of this local
copy and then do a single commit I get a lot of errors about not having
a "working copy".
When I try to do a bunch of mkdir's on the depot, and then add's, I get
errors about the directories already existing!

I am stuck in this process.

As for keeping the depot and repository synchronized - the plan was to
analyze the perforce changes to figure out what might have changed and
for all files that are supposed to be in subversion.

This process would be applied to the local copy of the perforce depot
each time a perforce change was submitted (post submit) in perforce:

1) files that were edited in perforce will simply be added to a list to
be committed in subversion
2) if a file was added in perforce, I will simply "add" it in
subversion and add it to the commit list
3) if a file was deleted in perforce, I will "delete" it in subversion
and add it to the commit list
4) if a file was branched and then deleted in perforce, I will "rename"
it in subversion, and add it to the commit list
5) if a file was branched from a file that isn't supposed to be in
subversion, I'll simply "add" it to the commit list
6) if the file was branched from and to a file in subversion and not
deleted, I will "copy" it and add it to the commit list
7) the entire commit list will be committed in a single subversion
commit

Subversion has issues with deleting files that aren't in the "working
copy" (which is how it would be after the perforce submit was done), or
rename files after they have been branch/deleted in perforce, or add
new files in new directories, if they already exist (which they would,
post a perforce submit). There are other "error" conditions too.

Does anyone have any idea on how to, and/or code, to do the above?

THANKS - Yossie

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 12 18:18:57 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.