RE: Repository as Branch

Normally we would checkout the file from core, make the changes and
checkin the file to the new repository so there wouldn't be a copy in
the new repository.

There are very few, maybe 2 or 3, branches in the customer repositories,
but many tags. When we send out a build we tag the core repository and
the customer repository with the same build identifier so some tags are
also the same across the repositories. 

I was hoping to have a repository layout like:
ApplicationSuite\tags\
                      Core tags
                      Customer tags
                \trunk\
                       Core project folders
                \branches\
                          \<customer name>\
                                           Customer project folders

So that it's very easy to see what went into a build by checking out the
appropriate tag from ApplicationSuite\tags\<build identifier> and to
make a customer build you can just checkout ApplicationSuite\trunk and
ApplicationSuite\branches\<customer name>. 

Currently the customer repositories contain a sub-set of the core
project folders plus some additional project folders specific to that
customer.

Thanks,
Vicky.
 

-----Original Message-----
From: Michael Haggerty [mailto:[email protected]] 
Sent: 22 April 2010 10:19
To: Vicky Chester
Cc: [email protected]
Subject: Re: Repository as Branch

Vicky Chester wrote:
> When we created the customer's CVS repositories, we just took a copy 
> of the working copy from the core repository and checked it into a new

> repository, rather than copying the repository itself. It sounds like 
> this wouldn't provide enough information to link the history together;

> there would just be the date the customer file was checked in, which 
> might not be the date it was branched.

If you always checked the snapshot into the new repository *before*
making changes, then it might be possible to find the branching point
based on the contents of the files being identical.  Otherwise it would
be very tricky.

> Setting up the fake branches sounds like the most straightforward 
> solution. Would this give a problem merging the branch changes back 
> into the core later on?

Merging will not work because (1) SVN doesn't know that the branch is
related to the trunk and (2) SVN doesn't know which trunk revisions are
already on the branch.

You could create fake merge info based on some external knowledge about
when the branches diverged.  But I'm not sure; it might be that SVN will
refuse to merge anyway because of (1).

By the way, you didn't mention whether the individual CVS repositories
*themselves* have branches and tags.  This could change how you want to
configure the conversion.

Michael

________________________________________________________________________
This e-mail from Ultra Electronics Holdings plc and any attachments to it are confidential to the intended recipient and may also be privileged. If you have received it in error please notify the sender and delete it from your system. If you are not the intended recipient you must not copy it or use it for any purpose nor disclose or distribute its contents to any other person. All communications may be subject to interception or monitoring for operational and/or security purposes. Please rely on your own virus checking as the sender cannot accept any liability for any damage arising from any bug or virus infection. Ultra Electronics Holdings plc is a company registered in England and Wales, registration number 2830397. The address of its registered office is 417 Bridport Road, Greenford, Middlesex, UB6 8UA.

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2592419

To unsubscribe from this discussion, e-mail: [[email protected]].