|
Replies:
20
-
Last Post:
Jun 18, 2014 3:09 AM
Last Post By: Arthur Hoornweg
|
|
|
Posts:
40
Registered:
9/26/02
|
|
Question for many of you using version control.
Using Delphi for most of our projects. My projects use a common core of units/forms and then the project specific code. I use Delphi under VM and have created two mapped drives.
M:\ is the drive for my projects
Q:\ is the drive for my common code.
So my project structure is:
M:\MyProject1
FORMS
PASONLY
BIN
M:\MyProject2
FORMS
PASONLY
BIN
Q:\COMMON
FORMS
PASONLY
If I had all the stuff in my MyProject1 or MyProject2 directly, GIT or other versioning would be a breeze. However with this structure, where MyProject1 has its own stuff and some units in COMMON and MyProject2 having its own stuff along with the same or other units in COMMON, it doesn't lend itself to this.
Any input on how I could handle this to use versioning properly.
Thank you in advance.
Lance |
|
|
Posts:
2,414
Registered:
9/22/99
|
|
Lance Rasmussen wrote:
Any input on how I could handle this to use versioning properly.
Have a repository for each project, and a separate one for the Common
code.
--
Nick
Delphi Programming is Fun |
|
|
|
|
Posts:
40
Registered:
9/26/02
|
|
Thanks Nick!
Even though the Project file would include links to the other repository, the folder for the project is fine being in it's own repository and same with Common?
Any drawback or gotchas doing it this way? Sounds logical to me, though.
Lance
Lance Rasmussen wrote:
Any input on how I could handle this to use versioning properly.
Have a repository for each project, and a separate one for the Common
code.
--
Nick
Delphi Programming is Fun |
|
|
|
|
Posts:
26
Registered:
9/26/99
|
|
I use Mercurial this way. Works nicely. The only rule you have to follow
is to always have your PROJECT and COMMON directories in the same
relation to each other, as that is how Delphi will know things.
/Anders
Lance Rasmussen skrev 2014-06-04 23:05:
Thanks Nick!
Even though the Project file would include links to the other repository, the folder for the project is fine being in it's own repository and same with Common?
Any drawback or gotchas doing it this way? Sounds logical to me, though.
Lance
Lance Rasmussen wrote:
Any input on how I could handle this to use versioning properly.
Have a repository for each project, and a separate one for the Common
code.
--
Nick
Delphi Programming is Fun |
|
|
|
|
Posts:
21
Registered:
12/26/01
|
|
On 04/06/2014 22:24, Anders Gustavsson wrote:
I use Mercurial this way. Works nicely. The only rule you have to follow
is to always have your PROJECT and COMMON directories in the same
relation to each other, as that is how Delphi will know things.
/Anders
Lance Rasmussen skrev 2014-06-04 23:05:
Thanks Nick!
Even though the Project file would include links to the other repository, the folder for the project is fine being in it's own repository and same with Common?
Any drawback or gotchas doing it this way? Sounds logical to me, though.
Lance
Lance Rasmussen wrote:
Any input on how I could handle this to use versioning properly.
Have a repository for each project, and a separate one for the Common
code.
--
Nick
Delphi Programming is Fun
Agreed.
I do this in Mercurial, however I would also put the repos into a parent
repo to keep them all in sync, otherwise how do you know which versions
of each repo will work together?
CB |
|
|
|
|
Posts:
26
Registered:
9/26/99
|
|
That's a problem of course  One of the most usual problems at my site
actually - forgetting to sync the common utilities repo. On the other
hand we have never had any big problems with this. When we deliver a
version we stamp all repos for that version, usually takes care of that
problem.
/Anders
Charles B skrev 2014-06-10 15:36:
On 04/06/2014 22:24, Anders Gustavsson wrote:
I use Mercurial this way. Works nicely. The only rule you have to follow
is to always have your PROJECT and COMMON directories in the same
relation to each other, as that is how Delphi will know things.
/Anders
Agreed.
I do this in Mercurial, however I would also put the repos into a parent
repo to keep them all in sync, otherwise how do you know which versions
of each repo will work together?
CB
|
|
|
|
|
Posts:
152
Registered:
5/25/01
|
|
On 2014-06-10 17:52, Anders Gustavsson wrote:
That's a problem of course One of the most usual problems at my site
actually - forgetting to sync the common utilities repo.
Simply create a batch file or bash script to pull the latest code from
all repositories in question. Problem solved with minimum effort. 
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/ |
|
|
|
|
Posts:
21
Registered:
12/26/01
|
|
On 11/06/2014 20:50, Graeme Geldenhuys wrote:
On 2014-06-10 17:52, Anders Gustavsson wrote:
That's a problem of course One of the most usual problems at my site
actually - forgetting to sync the common utilities repo.
Simply create a batch file or bash script to pull the latest code from
all repositories in question. Problem solved with minimum effort.
Regards,
- Graeme -
The other advantage of a parent repo is that you can clone/push/pull all
the subrepos together with one click. This is very handy when you have a
bigger project with 20+ subrepos.
Also your batch file will need some editing to get you back to a
specific version across all subrepos and you won't have a nice list to
browse.
It also scans all your subrepos so you can easily see which ones you
have changed.
You can also store your groupproj in the parent repo.
CB |
|
|
|
|
Posts:
2,414
Registered:
9/22/99
|
|
Lance Rasmussen wrote:
Any drawback or gotchas doing it this way? Sounds logical to me,
though.
Git requires that an entire repository be in the same directory. (Sub
directories are fine, but the project has to have a single root.)
Cross-references in code won't matter at all. Git doesn't care what
your code does.
--
Nick
Delphi Programming is Fun |
|
|
|
|
Posts:
601
Registered:
1/5/09
|
|
Lance Rasmussen wrote:
Even though the Project file would include links to the other repository, the folder for the project is fine being in it's own repository and same with Common?
Any drawback or gotchas doing it this way? Sounds logical to me, though.
My question would be: Why does the project contain links to anything from the common repository?
I guess you are directly adding files from common to the project
You can use the search path for that (and use a environment variable for the common directory). |
|
|
|
|
Posts:
414
Registered:
6/2/98
|
|
My question would be: Why does the project contain links to anything from the common repository?
I guess you are directly adding files from common to the project
You can use the search path for that (and use a environment variable for the common directory).
The problem with referencing a common lib through a path variable is that you can't reconstruct what particular version of the lib was used by a particular revision of your project. You can't "go back in time", so to speak, and re-compile an old version of your application and get the exact same binary.
What I do (using subversion) is to create a folder "externals" in my project directory and let Subversion reference all common libraries in there. Sure it's a lot of overhead on disk and I must "update" the externals folder regularly. I do that at the beginning of my build script anyway. And every time I release a version, I create a svn "tag" in my build script. The advantage is that I should be able to reconstruct any old version of my program and get the same binary when I compile.
|
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 17.06.2014 16:39, schrieb Arthur Hoornweg:
My question would be: Why does the project contain links to anything from the common repository?
I guess you are directly adding files from common to the project
You can use the search path for that (and use a environment variable for the common directory).
The problem with referencing a common lib through a path variable is that you can't reconstruct what particular version of the lib was used by a particular revision of your project. You can't "go back in time", so to speak, and re-compile an old version of your application and get the exact same binary.
What I do (using subversion) is to create a folder "externals" in my project directory and let Subversion reference all common libraries in there. Sure it's a lot of overhead on disk and I must "update" the externals folder regularly. I do that at the beginning of my build script anyway. And every time I release a version, I create a svn "tag" in my build script. The advantage is that I should be able to reconstruct any old version of my program and get the same binary when I compile.
Hello,
I'm using SVN as well and ran into a problem with externals lately.
Maybe you know something about it.
My common libraries are in their own folder within the repository and
there in subfolder trunk.
I created a new project, imported it into that same repositiony and
wanted to have some of my shared stuff but not all as externals. Ok,
started to define some externals property for the first needed subfolder
of the trunk folder and specifiying the following path within my working
copy as target to check out this externals to:
common\MyExternal1
I repeated this with different subfolders from my common unit's trunk
dir and always specifying common\MyExternal<n> as target with ever
increasing n.
But when applying the change and doing a checkout SVN always checked out
all stuff from my trunk folder in the repository into each of those
subfolders under common.
Why does he repeat himself? This wasn't what I wanted nor what I think I
specified! I'm using a quite updated TortoiseSVN as client.
All I could do was to get all my common stuff checked out as externals
under the common subfolder in the project directory.
Greetings
Markus |
|
|
|
|
Posts:
414
Registered:
6/2/98
|
|
Hi Markus,
Assume I have a common lib that looks like this:
mylib\subfolder1
mylib\subfolder2
mylib\subfolder3
and I want to reference just "subfolder1" as an externals in my current project:
- Create a folder "externals" in my project, right-click that folder, then "TortoiseSVN->add"
- Keep the folder empty (do not create sub-folders manually)
- Commit the project
- Right-click the "externals" folder, select "TortoiseSVN->Properties",
- Select "new - Externals"
In the dialog:
-Set local path="mylibsubfolder1"
-Set URL=https://myserver:8443/svn/mylib/trunk/subfolder1
-Either peg to a specific revision or use the "head" revision.
-Confirm.
-Commit the project.
-Now either right-click the "externals" folder and update it, or just update the whole project. It will pull in the correct sub-folder. |
|
|
|
|
Posts:
349
Registered:
8/2/02
|
|
Nick Hodges wrote:
Lance Rasmussen wrote:
Any input on how I could handle this to use versioning properly.
Have a repository for each project, and a separate one for the Common
code.
I have the same sort of problem as Lance, though I'm less organized than he is, and I use Hg.
But, whenever I change the program I'm working on and want to VC it, I have to remember where-all all the code actually resides, and check in each repository.
I understand that theoretically I could write batch files, but then I'd have to track them, too.
I'm too old to bother, so lots of my code doesn't get VCed. Too bad.
--
nhoJ |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 05.06.2014 06:06, schrieb John Treder:
Nick Hodges wrote:
Lance Rasmussen wrote:
Any input on how I could handle this to use versioning properly.
Have a repository for each project, and a separate one for the Common
code.
I have the same sort of problem as Lance, though I'm less organized than he is, and I use Hg.
But, whenever I change the program I'm working on and want to VC it, I have to remember where-all all the code actually resides, and check in each repository.
I understand that theoretically I could write batch files, but then I'd have to track them, too.
I'm too old to bother, so lots of my code doesn't get VCed. Too bad.
Hello,
you could use externals from SVN, That would mean that on the server one
directory holds your common stuff, other directories your individual
projects and on the local HDD each project contains all the common code
it needs in a subdirectory of that project.
When transfering changes made to the common code they will end up in the
common code's folder on the server.
Greetings
Markus |
|
|
|
|
Posts:
152
Registered:
5/25/01
|
|
On 2014-06-04 21:24, Nick Hodges wrote:
Have a repository for each project, and a separate one for the Common
code.
Exactly what I would have suggested too.
Lance, think of the Common code as a 3rd party "component". Your
projects need that "component" to compile and work. I wouldn't normally
put 3rd party components in the same source repository as my projects. I
would have a separate repository for them.
Regards,
- Graeme - |
|
|
|
|
Posts:
414
Registered:
6/2/98
|
|
Lance, think of the Common code as a 3rd party "component". Your
projects need that "component" to compile and work. I wouldn't normally
put 3rd party components in the same source repository as my projects. I
would have a separate repository for them.
That still leaves you with the problem that you can't reconstruct what revision of "common" was used for a particular revision X of your project. So if a customer reports a GPF at address XXXX:YYYY, you can't reconstruct where that was in the source code !
|
|
|
|
|
Posts:
397
Registered:
10/10/99
|
|
On 5/06/2014 5:57 AM, Lance Rasmussen wrote:
Any input on how I could handle this to use versioning properly.
I use a separate hg repository for my library code, and use symlinks to
map it into a folder in my project repository (and add that folder to
the hgignore in my project repository).
If it's something I use on lots of projects (for example, DUnitX) then I
create an environment variable in delphi and add the varible to the
project search path - e.g : $(DUNITX)
--
Regards
Vincent Parrett
VSoft Technologies Pty Ltd
http://www.finalbuilder.com
Blog: http://www.finalbuilder.com/resources/blogs.aspx
Automate your Software builds with FinalBuilder. |
|
|
|
|
Posts:
40
Registered:
9/26/02
|
|
Vincent,
So for Project X:
M:\MyProject1
FORMS
PASONLY
BIN
COMMONLINK (Symlink to Q:\COMMON)
Sill have MyProject1 Repository and Common Repository?
On 5/06/2014 5:57 AM, Lance Rasmussen wrote:
Any input on how I could handle this to use versioning properly.
I use a separate hg repository for my library code, and use symlinks to
map it into a folder in my project repository (and add that folder to
the hgignore in my project repository).
If it's something I use on lots of projects (for example, DUnitX) then I
create an environment variable in delphi and add the varible to the
project search path - e.g : $(DUNITX)
--
Regards
Vincent Parrett
VSoft Technologies Pty Ltd
http://www.finalbuilder.com
Blog: http://www.finalbuilder.com/resources/blogs.aspx
Automate your Software builds with FinalBuilder. |
|
|
|
|
Posts:
397
Registered:
10/10/99
|
|
On 8/06/2014 4:42 AM, Lance Rasmussen wrote:
Vincent,
So for Project X:
M:\MyProject1
FORMS
PASONLY
BIN
COMMONLINK (Symlink to Q:\COMMON)
Sill have MyProject1 Repository and Common Repository?
Yes, but you still need to add COMMONLINK to your .gitignore for your
project repo, git doesn't know it's a symlink and will see it as part of
your repo.
This is the technique we use for all our projects now, and it works
really well.
It also allows us to have the common and project repos as separate repos
in Continua CI, so we can trigger builds on changes to the common repo
as well as the project repo. We can also easily map the common repo to
the correct location using Repository Rules, e.g.
#Source rules
#---------------------------------------------------
#export all source to agent workspace
$Source.FBATSource$ > $Workspace$\Src
$Source.FBATLibraries$ > $Workspace$\Src\Libs
--
Regards
Vincent Parrett
VSoft Technologies Pty Ltd
http://www.finalbuilder.com
Blog: http://www.finalbuilder.com/resources/blogs.aspx
Automate your Software builds with FinalBuilder. |
|
|
|
|
Posts:
40
Registered:
8/5/07
|
|
|
In Subversion, you can use externals for this. I presume all the distributed version control systems that the cool kids have similar functionality.
Put your common code in a repository
In each project, create a subfolder and mark it as an external, linked back to the common code repository. You can link it either a particular revision of the common code library, or the HEAD. Then, anyone you checks out our project will also get the common library in a defined location in their project. You don't have to make a rule that the common project has to be checked out in a specific relative folder location to each library project. Subversion will ensure that happens for you within your current project.
It also allows you to have different projects linked to different revisions of your common project. And if you update a project to work with a newer version of the common project, you just update the external for that project, and all other people using that project will get the correct version of the common project when they next update.
Externals used to be very slow in older versions of subversion, but that has improved dramatically in recent years.
|
|
|
|
Legend
|
|
Helpful Answer
(5 pts)
|
|
Correct Answer
(10 pts)
|
|
Connect with Us