CVS repository and file extensions
Peter Seibel
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
Pete Fraser
.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" <webq...@web.de> wrote in message
news:l2c3d0hmv9eiflarm...@4ax.com...
Tamas Demjen
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
Dennis Jones
The problem with multiple users and project files is that the BCB IDE likes
to screw 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
Simon Macneall
> 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
R.F. Pels
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
Dennis Jones
news:opr9r2l7wu2nqexn@lightyear...
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
Rodrigo Gómez
It is fixed in BCB6 :)
--
Rodrigo Gómez
http://rgomez.msa.com.mx/gallery/
Simon Macneall
>
> 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
Dennis Jones
> On Fri, 18 Jun 2004 21:54:25 -0700, Dennis Jones <nos...@bogus.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