Board index » cppbuilder » CVS repository and file extensions

CVS repository and file extensions


2004-06-17 11:02:11 PM
cppbuilder15
Hallo,
I'm testing CVS at the moment and I'm
not shure witch files have to be imported
to the repository.
If more persons are working in a project
I know that the import of *.dsk files
are not a good idea. But what's with the
*.res and the *.bpk files. They seem to
belong to the project, but isn't it a
source of conflicts.
Thanks in advance
Peter Seibel
 
 

Re:CVS repository and file extensions

These are the types that I add to CVS:
.cpp, .hpp .h .bpr .bpg .bpk .res .dfm(as text)
all other types I ignore (in .cvsignore file) (except for the one's that
i've forgotten<g>)
Rgds Pete
"Peter Seibel" < XXXX@XXXXX.COM >wrote in message
Quote
Hallo,

I'm testing CVS at the moment and I'm
not shure witch files have to be imported
to the repository.

If more persons are working in a project
I know that the import of *.dsk files
are not a good idea. But what's with the
*.res and the *.bpk files. They seem to
belong to the project, but isn't it a
source of conflicts.

Thanks in advance
Peter Seibel

 

Re:CVS repository and file extensions

You might want to try Subversion (SVN) before you decide. It has several
advantages over CVS.
Here's my SVN exclude mask:
thumbs.db *.exe *.dll *.obj *.ncb *.lib *.idb *.pdb *.ilk *.msi *.res
*.pch *.suo *.aps *.*~ *.~* ~*.* *.dsk *.#* *.csm *.tds *.ddp
There's no include mask in SVN; it's *.*.
I put additional files and directories on the ignore list on demand. I
don't version the .dsk files, but I version the project's main .res
file, because it contains the application's icon and version
information. If you have 3rd party .obj / .lib dependencies, make sure
that you either version them or make backups, just in case you lose your
hard disk. The .bpk file is the project, it should be versioned. I put
the final output in the Debug directory and put that on the ignore list.
I also version my Inno Setup install scripts, but not the actual files
needed for the setup. I just make a backup of those. I don't version the
3rd party components but make a simple backup instead. I also version
the artwork (PNG/BMP images that go to a .res file). It's a good idea to
make the IDE generate textual .dfm files, not binary. I don't version
the .ddp files belonging to each form, because I don't use them.
As a shell integration, I recommend TortoiseSVN/TortoiseCVS under Windows.
Just my 2c worth...
Tom
Peter Seibel wrote:
Quote
Hallo,

I'm testing CVS at the moment and I'm
not shure witch files have to be imported
to the repository.

If more persons are working in a project
I know that the import of *.dsk files
are not a good idea. But what's with the
*.res and the *.bpk files. They seem to
belong to the project, but isn't it a
source of conflicts.

Thanks in advance
Peter Seibel

 

{smallsort}

Re:CVS repository and file extensions

"Peter Seibel" < XXXX@XXXXX.COM >wrote in message
Quote
Hallo,

I'm testing CVS at the moment and I'm
not shure witch files have to be imported
to the repository.

If more persons are working in a project
I know that the import of *.dsk files
are not a good idea. But what's with the
*.res and the *.bpk files. They seem to
belong to the project, but isn't it a
source of conflicts.
The problem with multiple users and project files is that the BCB IDE likes
to{*word*222}with the output (final/lib/obj) directories. The IDE will change
them without your permission, unless you use an explicit path (this is true
in BCB5 and earlier -- don't know if it was fixed in BCB6). This can be
problematic for multiple users sharing the project files because they might
have their systems set up differently, and as soon as they make a change to
the project options, the IDE will quietly modify the output directories
based on the current system, replacing drive letters, etc. The workaround
I've used is to use a subst'ed drive (using the "subst" command) on which
all output directories will reside, and use that drive with explicit paths
in the output directory fields. Then, each user can define his/her subst'ed
drive letter as appropriate, without worrying about how other users have
their systems configured. Other than that, sharing project files works
fine.
- Dennis
 

Re:CVS repository and file extensions

On Thu, 17 Jun 2004 22:37:23 -0700, Dennis Jones < XXXX@XXXXX.COM >wrote:
Quote
The workaround
I've used is to use a subst'ed drive (using the "subst" command) on which
all output directories will reside, and use that drive with explicit
paths
in the output directory fields. Then, each user can define his/her
subst'ed
drive letter as appropriate, without worrying about how other users have
their systems configured. Other than that, sharing project files works
fine.

- Dennis


We use a system variable that points to the base CVS checkout path. This
allows all includes, library paths and intermediate output to use them,
and just leave final output which must be a relative path (for some reason
BCB won't accept system variables in the final output path)...
Simon
 

Re:CVS repository and file extensions

Peter Seibel wrote:
Quote
I'm testing CVS at the moment and I'm not shure witch files have to be
imported to the repository.

If more persons are working in a project I know that the import of *.dsk
files are not a good idea. But what's with the *.res and the *.bpk files.
They seem to belong to the project, but isn't it a source of conflicts.
Anything that's 'generated' and anything that's 'personal' doesn't belong in
the CVS repository. However, an explanation of how to set up the project
files and the actual project file of the person responsible for doing
integration and/or check builds /does/ belong in the repository IMHO, but
preferably not in a place where it interferes with the day-to-day affairs.
--
Ruurd
 

Re:CVS repository and file extensions

"Simon Macneall" <macneall@iinet-dot-net-dot-au>wrote in message
Quote
On Thu, 17 Jun 2004 22:37:23 -0700, Dennis Jones < XXXX@XXXXX.COM >wrote:

We use a system variable that points to the base CVS checkout path. This
allows all includes, library paths and intermediate output to use them,
and just leave final output which must be a relative path (for some reason
BCB won't accept system variables in the final output path)...
I'm surprised you were able to make system variables work at all. In my
case, I just make everything absolute (no relative paths), and that has been
working for several years without any problems.
- Dennis
 

Re:CVS repository and file extensions

Quote
in BCB5 and earlier -- don't know if it was fixed in BCB6). This can be
It is fixed in BCB6 :)
--
Rodrigo Gómez
rgomez.msa.com.mx/gallery/
 

Re:CVS repository and file extensions

On Fri, 18 Jun 2004 21:54:25 -0700, Dennis Jones < XXXX@XXXXX.COM >wrote:
Quote

I'm surprised you were able to make system variables work at all. In my
case, I just make everything absolute (no relative paths), and that has
been
working for several years without any problems.

The reason we didn't do that is that different developers check out to
different locations, so absolute paths were out. We started using relative
paths, and this worked ok, but was a pain to set up and if you shifted a
project, nothing worked. I think system variables got a fair bit better in
BCB6, up to the stage that it works fine for us except for intermediate
output.
Simon
 

Re:CVS repository and file extensions

"Simon Macneall" <macneall@iinet-dot-net-dot-au>wrote in message
Quote
On Fri, 18 Jun 2004 21:54:25 -0700, Dennis Jones < XXXX@XXXXX.COM >wrote:

>
>I'm surprised you were able to make system variables work at all. In my
>case, I just make everything absolute (no relative paths), and that has
>been
>working for several years without any problems.
>
The reason we didn't do that is that different developers check out to
different locations, so absolute paths were out.
That was exactly my point in using subst'ed drive letters. Each developer
checks out his local copy to wherever he wants to, but uses the 'subst'
command to create a drive letter that points to the checked out copy. Since
every developer must use the same subst'ed drive letter, there's no problem
with varying paths, and you can use absolute paths that the IDE won't screw
up-- problem solved.
- Dennis