headers
Matthew J Fletcher | 11 May 2009 16:27
Picon
Favicon

Re: Nightly Builds?

Hi,

 >> Unless I am missing something, the last nightly build was 30 April 
 >>2008.
 >> Any idea when the next one will be? There was a bunch of patches by
 >> Alexander Gavrilov in late May 2008 that I was hoping would appear 
in >>a build soon.
 >>
 >
 >Yeah, April 30 sounds about right, that's when I changed my desktop PC
 >(aka build machine) from Windows to Ubuntu. :) I do have virtualbox
 >running on it now though, so I'll look into getting the builds running
 >again...

The latest nightly is still 30th April, would it be possible get another 
build to incorporate the fixes contributed since then ?

regards.

---
Matthew J Fletcher
Serck Controls Ltd
Firmware/Software

Tel: 02476 515089
mfletcher <at> serck-controls.co.uk

**********************************************************************
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
A company registered in England Reg. No. 4353634
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew J Fletcher | 11 May 2009 16:30
Picon
Favicon

Conversion of projects with 'shared' files

Hi,

vss2svn does a very good job of importing the history and the project 
layout, unfortunately it does not seem to cope so well with files that 
have been shared in VSS between projects.

Would it be possible to modify the script to use the 'export' property 
of SVN, not being an expert on such matters i am not sure if the two 
functionalities are the same.

regards.

---
Matthew J Fletcher
Serck Controls Ltd
Firmware/Software

Tel: 02476 515089
mfletcher <at> serck-controls.co.uk

**********************************************************************
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
A company registered in England Reg. No. 4353634
Tel: +44 (0) 24 7630 5050   Fax: +44 (0) 24 7630 2437
Web: www.serck-controls.com  Admin: post <at> serck-controls.co.uk
A subsidiary of Serck Controls Pty. Ltd. 
**********************************************************************
This email and files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they 
are addressed. If you have received this email in error please notify
(Continue reading)

Permalink | Reply | 3 comments |
headers
Luis A. Montes | 11 May 2009 21:12
Favicon

Re: Conversion of projects with 'shared' files

Hi,

I've been trying to work around the same problem. I'm not a Perl expert,
so I couldn't really understand what vss2svn is doing. So I just created
a shell script (I'm better at that) that reads up an intermediate output
(the output from ssphys) and creates file externals on the HEAD revision
of the svn repository.

There is a remaining problem and it's related to what you suspected: svn
file externals and VSS shared files are not semantically the same.
Close, but not the same. In subversion a shared file has to live
somewhere connected to your tree. If you delete that file and other
projects were pointing to it, there is no way to know that happened
until you try to get one of the other projects and the file is found
missing. The only workaround I've been able to come up with is to create
pre-commit hook scripts that checks for that and moves the source of the
file to one of the remaining projects.

Other problem is that looking at the source file you have no easy way to
know that it is being used as a source for a share, so you don't really
know that you have to "unshare"-it before modifying it in non-compatible
ways.

Perhaps the best way to deal with that problem, now that I think about
it, is to have a shared repository tree that mirrors the repository
without the externals. Every time you try to link a file using the
svn:external you would delete the file in the source and make BOTH
source and target point to the shared tree. That way you always know
that the file is shared and the semantics is closer to that of VSS.
Notice that having a single shared folder won't work because there is
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthew J Fletcher | 12 May 2009 08:59
Picon
Favicon

Re: Conversion of projects with 'shared' files

Luis A. Montes wrote:
> Hi,
> 
> I've been trying to work around the same problem. I'm not a Perl expert,
> so I couldn't really understand what vss2svn is doing. So I just created
> a shell script (I'm better at that) that reads up an intermediate output
> (the output from ssphys) and creates file externals on the HEAD revision
> of the svn repository.
> 
> There is a remaining problem and it's related to what you suspected: svn
> file externals and VSS shared files are not semantically the same.
> Close, but not the same. In subversion a shared file has to live
> somewhere connected to your tree. If you delete that file and other
> projects were pointing to it, there is no way to know that happened
> until you try to get one of the other projects and the file is found
> missing. The only workaround I've been able to come up with is to create
> pre-commit hook scripts that checks for that and moves the source of the
> file to one of the remaining projects.
> 
> Other problem is that looking at the source file you have no easy way to
> know that it is being used as a source for a share, so you don't really
> know that you have to "unshare"-it before modifying it in non-compatible
> ways.
> 
> Perhaps the best way to deal with that problem, now that I think about
> it, is to have a shared repository tree that mirrors the repository
> without the externals. Every time you try to link a file using the
> svn:external you would delete the file in the source and make BOTH
> source and target point to the shared tree. That way you always know
> that the file is shared and the semantics is closer to that of VSS.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Lee | 12 May 2009 12:38
Favicon

Re: Conversion of projects with 'shared' files

Matthew J Fletcher wrote:
> Hi,
>
> vss2svn does a very good job of importing the history and the project 
> layout, unfortunately it does not seem to cope so well with files that 
> have been shared in VSS between projects.
>
> Would it be possible to modify the script to use the 'export' property 
> of SVN, not being an expert on such matters i am not sure if the two 
> functionalities are the same.
>   

I converted a project that had made extensive use of VSS file sharing.

In the end, the best solution (and simpler than it may seem) was to do away with the file sharing - if a file is,
by design, to be used by several projects, it was put into a /common/include/ folder, or /common/sources/
for non-header files.

Each project then had ../common/include (or similar appropriate relative reference) added onto its
include path, and any common source files included from the ../common/sources folder. There was one
exception where a project used 90% of the same files as another - in this instance the project file was
changed using a search and replace to reference the files directly in their original location.

Almost all of this refactoring was done in VSS *before* conversion, making use of the sharing facility for this.

Afterwards, I'd wished this had been done years before, as several problems caused by shared files (e.g.
making a change in one project, and not realising it caused a problem for another project until after it was
checked in and the other project updated) went away, as both or all projects can be compiled before check-in.

One possibility I'd considered, but didn't do in the end, was to use share-and-branch for the share to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Attila Tajti | 26 May 2009 18:07
Picon
Gravatar

ssphys fix for Mac OS X

Hello, 

Recently I compiled ssphys on Mac OS X. Some changes was necessary for the autoconf things (configure.ac/Makefile.am) and a name collision (ssphys binary vs SSPhys subdirectory on the case insensitive filesystem) had to be resolved.

More info and patch is available here:


Unfortunately I have VC6 only so I could not fix the sln/vcproj files as necessary, so this likely breaks the Windows version, but the fix should be trivial.

Best regards



_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
Permalink | Reply | 1 comment |
headers
Toby Johnson | 27 May 2009 05:36
Picon

Re: ssphys fix for Mac OS X

Thanks Attila for the info and patch. Since I don't have a Mac to test on I didn't want to just add the patch directly but I have created a note about it on the wiki, with a link to your notes.

http://www.pumacode.org/projects/vss2svn/wiki/InstallingSsPhys

Toby

2009/5/26 Attila Tajti <attila.tajti <at> gmail.com>
Hello, 

Recently I compiled ssphys on Mac OS X. Some changes was necessary for the autoconf things (configure.ac/Makefile.am) and a name collision (ssphys binary vs SSPhys subdirectory on the case insensitive filesystem) had to be resolved.

More info and patch is available here:


Unfortunately I have VC6 only so I could not fix the sln/vcproj files as necessary, so this likely breaks the Windows version, but the fix should be trivial.

Best regards




_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user

_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
Permalink | Reply | 0 comments |

Gmane