Version Control for VHDL Project
AndreasWallner
I've worked on a few tiny VHDL projects in the past and since I have
to write a bigger project for my university, I wanted to ask how you
guys use source control on projects using multiple libraries.
I know how to use version control in general, the question is how to
work with those libraries. For example: Consider a design using some
sort of softcore processor and peripheral modules for that processor.
I would make a seperate library for each module as well as for the
processor itself. This way the modules itself could be reused. In that
case I would also use a different repository for each module (We use
Subversion and Git for Version control).
If I would do it that way, I would have a problem taging a specific
revision (for example the first version delivered to the client). Do
you use tags? Do you use SVN/Git externals/submodules? Do you
structurize you code in a way to make is neccesary to use more than
one "level" of libraries in you projects? (For example a Design using
an AES core itself using a librarie providing the S-Box for AES
(shared by AES and DES))?
I would really appreciate information how you handle multiple
libraries, because each scenario we thought of seems to be flawed in
some way.
The second reason I ask this is: While I do study electronics, I'm
also very much into programming. Because I that, a colleague and I
started working on a program to edit VHDL/Verilog Code, much like HDL
Designer from Mentor. (Yes we know this is a lot of work, and yes we
have done project in a reasonable size before to know what awaits us).
Although It is not ready to be tested in a real world situation, I was
interested how you handle such version control issues, so we might be
able to incorporate such functionality. (At the moment the only thing
it can do is managing various libraries and open VHDL files to edit
them)
I hope I have explained myself clear and not missed a note regarding
that issue in my search on the list.
Regards,
Andreas
Mike Treseler
> I've worked on a few tiny VHDL projects in the past and since I have
> to write a bigger project for my university, I wanted to ask how you
> guys use source control on projects using multiple libraries.
I prefer multiple packages, but one library (work) to
simplify the sources and be compatible with
vhdl-mode makefiles.
> The second reason I ask this is: While I do study electronics, I'm
> also very much into programming. Because I that, a colleague and I
> started working on a program to edit VHDL/Verilog Code, much like HDL
> Designer from Mentor.
Have a look at vhdl-mode first.
-- Mike Treseler
AndreasWallner
> AndreasWallner wrote:
> > I've worked on a few tiny VHDL projects in the past and since I have
> > to write a bigger project for my university, I wanted to ask how you
> > guys use source control on projects using multiple libraries.
>
> I prefer multiple packages, but one library (work) to
> simplify the sources and be compatible with
> vhdl-mode makefiles.
Ok, I think we misunderstood each other. Thats because I did not mean
library in the sense of an VHDL Library (like work or ieee), but
library in the sense of a module providing some sort of functionality.
(So more in the sense of a normal software library). Excuse me, but
that's the way HDL Designer uses the term library too...while writing
I forgot it could be misleading.
The question I had in mind was really more: How do you manage to track
the state of self written IP Cores and the top level project with your
version tracking system. Espacially if you want to tag the whole
project, how do you ensure the correct version of the used IP cores is
used.
I hope that cleared our misunderstanding.
> Have a look at vhdl-mode first.
I know vhdl-mode and it is somehow great...but it's not as much fun as
writing your own piece of software (everybody has to have a
hobby ;-) )
Regards,
Andreas
Mike Treseler
> The question I had in mind was really more: How do you manage to track
> the state of self written IP Cores and the top level project with your
> version tracking system. Especially if you want to tag the whole
> project, how do you ensure the correct version of the used IP cores is
> used.
There's little difference between tags and branches in Subversion.
Both are directories that are created by a copy.
If I don't commit changes, it stays a tag or "snapshot".
If I commit a change, it becomes a branch.
>> Have a look at vhdl-mode first.
> I know vhdl-mode and it is somehow great...but it's not as much fun as
> writing your own piece of software (everybody has to have a
> hobby ;-) )
Go for it.
But vhdl-mode sets the bar high.
-- Mike Treseler
KJ
"Mike Treseler" <mtre...@gmail.com> wrote in message
news:4A0F68F4...@gmail.com...
> AndreasWallner wrote:
>
>> The question I had in mind was really more: How do you manage to track
>> the state of self written IP Cores and the top level project with your
>> version tracking system. Especially if you want to tag the whole
>> project, how do you ensure the correct version of the used IP cores is
>> used.
>
> There's little difference between tags and branches in Subversion.
> Both are directories that are created by a copy.
> If I don't commit changes, it stays a tag or "snapshot".
> If I commit a change, it becomes a branch.
>
I think what Adreas is asking about has to do with reusable (or potentially)
reusable IP. You create some widget and put it into a Subversion (or other)
repository. Sometime later you're working on a *new* design that happens to
need the same widget. There are a couple ways to go about getting the old
IP
1. Copy/replicate. Export the IP you need into the folder for the new
design. Then when you check in the new design into its repository it's
archived. The drawback here is the usual thing that happens with
copy/paste, you've created a totally new widget that begins life exactly the
same as the first widget, but they can each evolve down different paths if
you find out later that you'd like to update the widget (in fact there is no
'the widget' anymore, there are 'two widgets', then three, four, more).
2. Have the new design reference widget. In Subversion you do this via the
'svn_external', the potential problem here is that the only way to totally
lock down exactly what you're getting for widget is to specify the revision
to pull when you reference the widget. This is OK if widget is firm and
solid, but a pain if widget is also undergoing development and you're still
in the development phase of your new thing that uses widget and you'd like
to get 'latest/greatest'. The pain then becomes at the end when you're
trying to exit that mode, going back into each of those svn_externals to
then specify the revision you want is a manual, prone to problems effort.
If you don't do this, then when you try to check out/export an archived
design your references to widget will pull the 'head' revision, not the
revision that existed at the time you wanted to archive.
3. Have the new design reference the new widget as in #2. But when you get
to the point of releasing something and want to be able to create a tag that
you can use as a real archive so that you go back and pull the design as it
really existed at some prior time, but still have the benefits of
referencing a single widget design when you're in development mode, then you
need to use 'svncopy.pl'
(http://svn.collab.net/repos/svn/trunk/contrib/client-side/svncopy/svncopy.README).
This is one particular area of source control where MS Source Safe beats
Subversion hands down. The fact that you can't reference a widget in some
repository and be able to later tag it down to a specific revision at design
complete without a lot of effort (#2) or having to use scripts to help along
the source control tool's weakness (#3) is a major weakness, 'specially
considering that this is after all a source control tool.
Kevin Jennings
Mike Treseler
> The question I had in mind was really more: How do you manage to track
> the state of self written IP Cores and the top level project with your
> version tracking system. Especially if you want to tag the whole
> project, how do you ensure the correct version of the used IP cores is
> used.
This is similar to the problem of two developers working on the same
module at the same time. Sometimes there are conflicts that have to be
manually merged.
I prefer KJ's "copy/replicate" method. My top priority is
to get the project finished. I can merge back changes to reusable
modules when the pressure is off.
-- Mike Treseler
Charles Gardiner
I have a number of reusable cores (varieties of Timers, Uarts,
wishbone-to-whatever adapters, dma controllers etc.) and link them into
a customer project as required by simply setting subversion externals.
Each 'core' is developed as a project on it's own.
Essentially, I have a repository for my reusable stuff, a different
repository for customer projects and so on.
I think one of the most important parts is a suitable directory
structure. If you design things regularily enough, it's not much of a
problem to include a core as part of another core and to include the
super-core as part of a customer project.
AndreasWallner
> I have been using subversion for this purpose for maybe three years now.
> I have a number of reusable cores (varieties of Timers, Uarts,
> wishbone-to-whatever adapters, dma controllers etc.) and link them into
> a customer project as required by simply setting subversion externals.
> Each 'core' is developed as a project on it's own.
>
> Essentially, I have a repository for my reusable stuff, a different
> repository for customer projects and so on.
Do you use a single repository for all your reusable stuff? With
subfolders for each IP?
> I think one of the most important parts is a suitable directory
> structure. If you design things regularily enough, it's not much of a
> problem to include a core as part of another core and to include the
> super-core as part of a customer project.
Would you mind telling me about the folder structure you use?
AndreasWallner
the first time...
> I think what Adreas is asking about has to do with reusable (or potentially)
> reusable IP. You create some widget and put it into a Subversion (or other)
> repository. Sometime later you're working on a *new* design that happens to
> need the same widget. There are a couple ways to go about getting the old
> IP
You are right on that point. Excuse me for not being clear here.
> 1. Copy/replicate.
We thought about that, but bringing the changes made to an core back
into the main repository is the hard part here, as you pointed out.
> 2. Have the new design reference widget.
Thanks for that information, I'll look into that subversion feature.
I didn't know svn provides that functionality.
(I never needed to use something like that on my previous projects
(especially since I do software projects (C/C++) most of the time,
there we mostly install the needed libraries to system paths, which is
not quite applicable for VHDL projects)
> 3. Have the new design reference the new widget as in #2. But when you get
> to the point of releasing something and want to be able to create a tag that
> you can use as a real archive...
I think you should really have a look at git, it is really easy to use
(after you have understood the differences from DVCS to traditional
VCSs ;-)) and provides a feature called 'submodule' which is excatly
what you described. If you create a tag, the content of the whole
project is saved, and since a submodule not only contains the location
of the imported repository, but also the precise commit currently
used, the state of the IP cores is also preserved
AndreasWallner
> to get the project finished. I can merge back changes to reusable
> modules when the pressure is off.
Since we are a university time is not a pressure (most of the time).
The bigger problem would be if people forget to push their changes
back into the IP core repository. If you have a disciplined
development team, or are developing alone I can imagine that this
would not be a problem, but my environment that could lead to serious
problem.
Like someone chaging an IP core, but introducing a bug, fixing that
bug in the project repository, but forgetting to push the changes into
the IP repo.
Other than that we would also loose the information who did specific
changes, and why...
KJ
"Charles Gardiner" <inv...@invalid.invalid> wrote in message
news:guou1n$e07$03$1...@news.t-online.com...
>
> Essentially, I have a repository for my reusable stuff, a different
> repository for customer projects and so on.
>
What method do you use to lock down the revision of the subversion external
references within the customer repository (for archival purposes) but still
allow the latest/greatest revision to be used for development (or future
customer enhancements)? svncopy.pl? Manually? Something else?
KJ
Charles Gardiner
>
> Do you use a single repository for all your reusable stuff? With
> subfolders for each IP?
>
Exactly, I use a single repository for the reusable stuff with each
having it's own substructure
>
> Would you mind telling me about the folder structure you use?
No Problem. This is only my suggestion, though. I'm sure at least 100
others will also work. I think the important thing is a structure that
is regular, reproducable and scalable but still flexible.
My (ASIC/FPGA) Project structure looks like this (not all line-breaks
are intentional). BTW, each reusable unit also has a similar structure.
design doc flow image impl reports resources scripts verify work
Sometimes there is a 'driver' directory here too.
From a chip perspective, design and impl are the important ones. 'impl'
contains target-specific stuff like PLLs, Memories etc. Often generated
by perl or tcl scripts in tool-related directories below 'scripts'
'design' has the further subdirectories
common top units
Under 'common', I have things like my utility libraries and frequently
used smaller blocks such as say FIFO controllers. (Yes, I prefer to roll
my own). These nearly all come from the reusable repository.
'top' usually just contains a core and top-level pin-out block. i.e. the
core is the only thing instanced in the 'top' block along with any
additional polarity inversions, tri-state etc.
The most interesting is the 'units' tree. This is a mix of
project-specific and reusable cores. Each unit can have it's own top
and/or units subdirectories depending on complexity. Often, there is
just a directory called 'verilog' or 'vhdl' directly under a unit,
containing the source code for that unit.
Looking at one of my current designs, the following as an excerpt from
below the <project_name>/design/units path:
credit_config lscc_pcie_wb01 wb_spi_ad7490_c32
Here, the first and last are project-specific, the middle one is from
the reusable repository and is a wishbone adapter for the Lattice PCIe
core. Running 'svn propget svn:externals' on this (middle one) gives:
lscc_pcie_wb01 -
top http://regulus/svn/SoC/lscc_pcie_wb01/trunk/design/top
units http://regulus/svn/SoC/lscc_pcie_wb01/trunk/design/units
So, the project-local dirs
<design_name>/design/units/lscc_pcie_wb01/top and
<design_name>/design/units/lscc_pcie_wb01/units are imported from the
reusable-stuff repository.
There is also a directory tree
<design_name>/design/units/lscc_pcie_wb01/config which is local to the
design and just contains a package taking care of some project-specific
configurations, but which is required by the files from the repository
(this is an example of what I mean above by flexible. A directory tree
that basically stradles the reusable and project repositories)
The test-bench resides below the 'verify' path and is very similar to
the directory structure below 'design'. Depending on the design, there
can be various BFMs etc. Reusable test-bench stuff gets hooked in here
the same way as above.
Beside all this, I have a collection of perl/java scripts for generating
make-files, testbench skeletons etc. which of course are designed to
work with this structure.
As I said, just look on this as food for thought. You may have other
requirements.
Best of luck with your projects.
Charles Gardiner
>
> What method do you use to lock down the revision of the subversion external
> references within the customer repository (for archival purposes) but still
> allow the latest/greatest revision to be used for development (or future
> customer enhancements)? svncopy.pl? Manually? Something else?
>
> KJ
>
>
I followed the subversion suggestions here. Each reusable unit (and of
course each customer project) has a tags, branches and trunk
subdirectory. Every project release to a customer is tagged (svn copy)
and the output of 'svn -R propget svn:externals .' documented just for
safety. Every version of a reusable unit included in a customer project
is also taken from an entry under //<svn_server>/SoC/<reuse_block>/tags
and never directly from the trunk
Continued development, fixes etc. to a resuable core are done as a
project on it's own (under trunk). If a customer gets an upgraded/fixed
version, I generally just remove the previous sub-tree to the reusable
block in his project and modify the svn:externals to pick up a new
tagged version.
Unfortunately, I'm currently running subversion Version 1.4.4. According
to my understanding, the newest releases give much better merging
options but I just don't have time to take my system down for a few days
at the moment. But it's on my task-list.
KJ
"Charles Gardiner" <inv...@invalid.invalid> wrote in message
> KJ schrieb:
>
>
>>
>> What method do you use to lock down the revision of the subversion
>> external
>> references within the customer repository (for archival purposes) but
>> still
>> allow the latest/greatest revision to be used for development (or future
>> customer enhancements)? svncopy.pl? Manually? Something else?
>>
>> KJ
>>
>>
>
> I followed the subversion suggestions here. Each reusable unit (and of
> course each customer project) has a tags, branches and trunk
> subdirectory. Every project release to a customer is tagged (svn copy)
> and the output of 'svn -R propget svn:externals .' documented just for
> safety.
Creating tags using 'svn copy' though doesn't lock down the revision of
externals when creating the tag so when you go back later to get the tag and
check it out, anything from an 'svn_external' will return the 'head'
revision of the referenced folder, not the revision that existed at the time
that you created the tag...good thing you have the 'svn -R propget
svn:externals .' documented so you know which revision was really used at
the time the tag was created.
Kevin Jennings
AndreasWallner
I'm really grateful.
I think we will try using the approach Charles presented, but we'll
stick with git as a version tracker.
I don't want to advertise git here, but you should really have a look
at it, as it provides exactly the functionality Kevin was missing from
this idea. (Tagging through all external imports)
Andreas Wallner
PS: Would you use an editor which forced you to use git?
AndreasWallner
feature (Mercurial calls them Nested Repositories, Bazaar Nested
Trees) if you don't like git.
Bazaar can also easily be used as a centralized VCS, that's just a
setting. They might be worth a look, especially for this issue.
Mike Treseler
> Since we are a university time is not a pressure (most of the time).
> The bigger problem would be if people forget to push their changes
> back into the IP core repository.
I don't follow.
Version control can't remind a developer to do that.
-- Mike Treseler
Andy Peters
> "Charles Gardiner" <inva...@invalid.invalid> wrote in message
Kevin,
I've been using Subversion for FPGA designs for quite awhile now and
I've come up with what I think is a reasonable workflow.
Of course lots of things are reusable, and anything that is so is a
separate project in the repository. As an overview, my repository
structure is as follows:
---------------------------------------------------------------
root\fpga\projects <-- All chip-level designs go here
\projects\A\tags\
\branches\
\trunk\src\ <-- VHDL goes here
\projects\A\trunk\fitter\ <- synthesis/P+R stuff
\projects\A\trunk\testbench\ <- obvious!
\fpga\models <- various simulation models for
testbenches
\fpga\modules <- resuable "cores" go here
\fpga\modules\spimaster\tags\
\branches\
\trunk\src
\trunk\testbench
\pwm\tags\
\branches\
\trunk\src\
\trunk\testbench\
----------------------------------------------------
Now here is how it works. When I'm doing a new FPGA design that needs
an existing module, I always use TAGGED versions of those modules.
This means I put the svn:externals property on the design's src
directory as follows:
spi svn://repo/fpga/modules/spi/tags/spi_v1.0.0/src
pwm svn://repo/fpga/modules/spi/tags/spi_v1.1.0/src
(don't forget the src, otherwise you get the testbench for the module
too!)
Now when you check out the FPGA design, you get the tagged (by
convention, immutable) versions of those modules.
If you are developing a new module along with your FPGA design, still
keep it as a module, but just include the trunk of that module until
you decide that it's ready for "release," at which point you tag it.
Oftentimes I will check out the submodule into its own working copy,
code it up, verify with the testbench, and commit, and only after
that's done will I add it to the externals for the larger design.
If you decide to change a tagged module, change the external to
reference either the trunk of that module, or create a branch of it.
Update the FPGA design's working copy and now you are developing on
the module's trunk. When you are finished and satisfied that the
module works as required, create a new tag, then change the chip
design's src directory's externals to reference the module's new tag.
Basically, then, when you decide to release the whole design, ALL of
the submodules pulled in by svn:externals should be TAGGED versions,
not from their respective trunks. So when you check out your design's
released tagged version you get what you expect, regardless of later
changes to any modules, which I suppose is the whole point of version
control.
I like to add the .bit and .mcs files to my design release tags, too.
Here's what I do. Before you tag your FPGA design for release, check
out a working copy (all tagged submodules!) _from the trunk_ and build
it. When complete, do an svn add on the .bit and .mcs files. (You
might wish to create a separate directory for these files under the
project root, and add that directory instead.) Do NOT commit the
change. Instead, create a tag from the _working copy_ (very easy in
TortoiseSVN). When that's done, your repo has a tagged release version
of the FPGA including .bit and .mcs. The working copy remains on the
Now, do an svn revert on the .bit and .mcs files because there's no
reason the trunk should contain build results.
Anyways, it's actually easier to use than to describe, and it works
for me.
-a
AndreasWallner
Yes it can: If a developer needs to copy the changed files back into
another folder and commit his changes into another folder (the
repository of the core) we won't be able to ensure all changes (e.g.
bugfixes) because people are just too lazy to do this, or pretend not
to have time for it. Since they are students like me they can't be
forced, and certainly cannot loose their job or something else because
of such problems.
If we use a system where you have to import IP cores as subtrees like
Kevin suggested, commiting the project results in a commit of the
changes made to the subtree, so the IP core repository is
automatically updated with the changes made in the project
repository.
That's how version control can remind you.
Regards,
Andreas Wallner
Mike Treseler
> If we use a system where you have to import IP cores as subtrees like
> Kevin suggested, commiting the project results in a commit of the
> changes made to the subtree, so the IP core repository is
> automatically updated with the changes made in the project
> repository.
I hear what you are saying, but this assumes
that all changes are worthy,
or that someone is monitoring
the core repository, fixing testbenches
and scripts to cover the changes as they come in.
-- Mike Treseler
MikeWhy
news:ljKPl.33384$ZP4....@nlpi067.nbdc.sbc.com...
>
> 3. Have the new design reference the new widget as in #2. But when you
> get to the point of releasing something and want to be able to create a
> tag that you can use as a real archive so that you go back and pull the
> design as it really existed at some prior time, but still have the
> benefits of referencing a single widget design when you're in development
> mode, then you need to use 'svncopy.pl'
> (http://svn.collab.net/repos/svn/trunk/contrib/client-side/svncopy/svncopy.README).
>
> This is one particular area of source control where MS Source Safe beats
> Subversion hands down. The fact that you can't reference a widget in some
> repository and be able to later tag it down to a specific revision at
> design complete without a lot of effort (#2) or having to use scripts to
> help along the source control tool's weakness (#3) is a major weakness,
> 'specially considering that this is after all a source control tool.
Unless I missed the full import of the context, for it to work in VSS, it
has to all reside in the one repository, and so works even better in SVN.
SVN doesn't need tags or labels. A single revision number refers to the
entire state of the repository, including branches. You run into trouble
only if your work spans different branches, but that's a problematic
workflow issue regardless of the version control tool. For example, your
project is in the trunk, but you branched the libraries to support your
local work. The better solution is to branch lower so they have a common
root. If they span repositories, ... you might want to reconsider the
repository schema.
MikeWhy
news:%0CQl.22636$as4....@nlpi069.nbdc.sbc.com...
[ps] Oops. Scratch that. I've successfully avoided needing SVN externals
altogether, but they solve the problem of cross branches or repositories.
Thought I'd save everyone the trouble of correcting me. Once the externals
are setup, the project can always be reverted to the right state for a given
revision.
MikeWhy
>
> Creating tags using 'svn copy' though doesn't lock down the revision of
> externals when creating the tag so when you go back later to get the tag
> and check it out, anything from an 'svn_external' will return the 'head'
> revision of the referenced folder, not the revision that existed at the
> time that you created the tag...
The externals property takes an optional revision number:
fooPath -rNnnn URL
Since properies are versioned, the externals will track properly when you
manually track the external revision.
KJ
> "KJ" <kkjenni...@sbcglobal.net> wrote in message
That's good if you really like *manually* setting revisions on all
svn_externals. When you're getting ready to release and really lock
down on a final version, the last thing you want is some manual
process like this to be in the loop.
From a 'two years down the road' support perspective of being able to
exactly recreate all source files as they really were at the time of
release, the last thing you want is to have to hope and pray that
someone manually did this to each and every svn_external (on each and
every release) when you know that they were under the gun to get the
thing released and out the door.
Neither scenario is a good one, which is why if you use svn_external
you really need to use something like svncopy.pl to create the tags
for release and not rely on 'svn copy' or TortoiseSVN or the methods
discussed by the Subversion folks to create a tag.
KJ
KJ
"MikeWhy" <boat042...@yahoo.com> wrote in message news:EeCQl.22637>>
>> entire state of the repository, including branches.
But the labels in VSS actually allow one to easily mark everything so that
you can come back years later and recover it exactly. I'm not pushing VSS,
actually I like Subversion and Tortoise better than VSS, I just happen to
use both.
> Once the externals are setup, the project can always be reverted to the
> right state for a given revision.
>
Try the following experiment (or just read along and trust that it really
turns out the way that I say it does...the ending has quite the twist for
those who think that Subversion tags actually do anything useful from an
archival standpoint)
1. Setup a new repository
2. Add new folders called 'Project1' and 'Project2' to the repo.
3. Export 'Project1' to some folder
4. Add the svn_external property to the working copy of 'Project1' to
reference 'Project2'.
5. Do an update to get Project2 into the working copy.
6. Create a new text file called 'Project2_File.txt' in the Project2 folder.
7. Edit Project2_File.txt so it has the single line of text 'This is line
#1'
8. Add Project2_File.txt into 'Project2' and commit the changes to both
'Project1' and 'Project2'.
At this point, what you've emulated is the creation of a new design called
'Project1' that refers to some presumably reusable module called 'Project2'.
Consider for the moment that reusable modules always begin life somewhere
and many times this begining is during the development of some bigger thing.
So in this case 'Project1' is the *bigger* thing, and 'Project2' is the
newly created (but intended to be reusable) module.
In this scenario both projects are likely both being developed concurrently
and, for the most part, up until towards the end of the development cycle
'Project1' will most likely always want to be referring to the
latest/greatest (i.e. the 'head' revision in Subversion-speak). For that
scenario then, one would most likely want to leave the revision off of the
'svn_external' reference thereby defaulting to the 'head'. You might not
want to, but indulge me. Anyway, so far, so good.
9. Create your tag of 'Project1' using 'svn copy' or TortoiseSVN so that you
get the warm fuzzy feeling that you've successfully archived away the
current state of 'Project1' at this moment in time confident that you can
come back at any time to recover this entire project exactly as it was left
after step #8. To do so you will of course be specifying the exact revision
of 'Project1' to use to create the tag. Lets say this tagged version of
'Project1' is put into the archive at 'Tags/Project1_1.0'
Step 9 emulates what one would be doing when you've completed development
and are getting ready to release. The purpose of the tag
'Tags/Project1_1.0' is to permanently archive away the 'Project1' design and
any of its subprojects for posterity so that they can be recreated at any
point in the future regardless of any future changes to either 'Project1' or
'Project2'.
10. Checkout 'Tags/Project1_1.0' to a folder 'Project1_1.0_Step10'
11. Open up the file ''Project1_1.0_Step10\Project2\Project2_File.txt' and
it will of course have one line of text "This is line #1"...again all is
well and good
12. Go back to the original working copy where you created 'Project1', or
better yet delete all of the folders so there are no working copies. Then
check out 'Project1' (not the archived tag, but the original) to create a
working copy in 'Project1-NEW'
13. Edit the file 'Project1-NEW\Project2\Project2_File.txt' by adding a new
line "This is line #2" and commit it to the repository.
Steps 12 and 13 emulate entering design changes into the 'trunk', perhaps to
add new functionality, bug fixes, documenation, whatever. You've dutifully
avoided changing the 'tag' branch, you've made modifications only to the
trunk as per all the Subversion recommended procedures (actually I've
skipped over the creating of a branch and the merge back into the trunk just
for simplicity).
14. Now let's checkout 'Tags/Project1_1.0' again, this time to the folder
'Project1_1.0_Step_14'
Step 14 is emulating the attempted recovery of the tag of 'Project1' as it
was archived back on step 9. This would be a normal support activity, the
re-creation of all of the source files as they existed at some previous time
to investigate some odd customer reported activity.
15. Open the file 'Project1_1.0_Step_14\Project2\Project2_File.txt'
16. Pick your jaw up, wipe the sweat off your brow, or do whatever it is
that you think is appropriate when you see that this file (checked out from
the safely and dutifully archived 'tag' remember) now has two lines of text
This is line #1
This is line #2
17. Explain to me how you think you've archived the actual source files and
can re-create any of your released builds because you've 'tagged' them.
---
Now this story could have had a happier ending. You could vehemently object
and say that in step #4 when the 'svn_external' was first added that by
golly you would never have let this go, you would always have specified a
particular revision. Fair enough, and if 'Project2' is always some locked
down, well debugged, never ever going to change thing and that's the only
type of thing you would ever reference via 'svn_external' you might have a
point. But remember the scenario I was painting, both 'Project1' and
'Project2' were being developed simultaneously, both subject to change.
I'll boldly make the following claims about such an approach
- Very, very little is ever likely to meet the standard of "locked down,
well debugged, never ever going to change"
- You're creating a lot more needless work for yourself by manually
specifying revisions for every 'svn_external'...and when you think about it,
this extra work is because the version control system you're using has
trouble recreating a specific revision.
- You haven't considered that others might not be quite as diligent as you
about always manually adding revisions, so then what?
A few questions come to mind: How much effort do you think is worth
expending to cover the omissions of others? Ask yourself why a highly
regarded version control system should have such a glaring deficiency in
actually being able to recover archived versions properly? Don't work
yourself into a dither though, help may be on the way.
The method to recover from all the bad things that you realized in step #16
might be are (but beware the bogey on step 22):
18. Google for svncopy.pl. Download it, it's a PERL script
19. Google for and download and install some version of PERL if necessary.
20. Go to your repository log and figure out which revision of your
repository created the tag that you did in Step #9. I'm sure you added a
log message entry during your commit to facilitate this ;)
21. Type in the following (replacing xxxx with the revision you determined
in #20, and of course replacing the repo links as appropriate for the source
and destination of the copy
perl svncopy.pl --tag --revision xxxx file:///C:/Mysvn/Project1
file:///C:/Mysvn/Tags/Project1_1.0-Svncopy
22. Hope that you don't get the error message:
Can't call method "temp_dir" on an undefined value at \program
files\subversion\svncopy.pl line 221.
23. If you're lucky with step #22, you should now have a correctly tagged
'Project1' that has really archived the entire revision. Repeat steps 12
and 13 and see if it really sticks. If so, then exhale.
If you're not so lucky on step #22 and get the error message, please post
the solution to this problem. Even Google failed to come up with the
solution although it appears many have run across this problem. If you're
stuck having this problem, exhale anyway, holding your breath doesn't really
help.
Kevin Jennings
P.S. I am looking for the solution to the error message in a Windows
environment if anyone can provide it.
P.P.S. Obviously this post has more to do with Subversion then VHDL so I
apologize but there do seem to be some misconceptions among this group about
just how useful a 'tag' really is from an archival perspective when using
'svn_external' to reference reusable widgets.
MikeWhy
might have saved you a lot of typing. Fundamentally, I agree with your
observation, that svn:externals have archival problems. But I come to a
different conclusion. If you need to use them, the externals must all have
explicit revision references. Otherwise, they are little more useful than
`ln -s` soft links to a local working copy of the foreign repository. In
fact, they are worse in some respects. You get the worst of both worlds:
archival issues, AND continual integration issues as you blindly track their
updates. The soft-link at least allows you control over when you update the
foreign source.
My day job is software. The revision id is post-processed into the binaries
and debug symbols so the toolchain can pull the right source versions for
autopsies. With unrestrained externals in the tree, traceability is already
compromised without talking about archiving. It isn't completely broken, as
the externals version can be narrowed _manually_ by approximate time and
date. But you should know that anything that interferes with a smooth
workflow on a 02:00 server outage brings painful wrath immediately.
The problem with SVN externals is not so much their implementation, but
their visibility. They're essentially hidden without tools that show clearly
the state, that they're external, and to which revision they are locked if
it is or isn't. I don't believe that Tortoise does this, but I have no
experience with externals. It was a wise rule: NO FREAKING EXTERNALS. I've
reaffirmed it with the thought exercise.
An additional comment below...
"KJ" <kkjen...@sbcglobal.net> wrote in message
news:6sMQl.16871$pr6....@flpi149.ffdc.sbc.com...
...
> 21. Type in the following (replacing xxxx with the revision you determined
> in #20, and of course replacing the repo links as appropriate for the
> source and destination of the copy
> perl svncopy.pl --tag --revision xxxx file:///C:/Mysvn/Project1
> file:///C:/Mysvn/Tags/Project1_1.0-Svncopy
> 22. Hope that you don't get the error message:
> Can't call method "temp_dir" on an undefined value at \program
> files\subversion\svncopy.pl line 221.
...
>
> P.S. I am looking for the solution to the error message in a Windows
> environment if anyone can provide it.
Many tools have a problem with spaces in the path name. Have you tried
simply moving the script to a directory with a simpler name? E:\tools and
E:\apps became my local convention after being bitten too many times by
cross-platform packages.
Mike Treseler
> I wish I had sent the <AOL>Me too!</AOL> earlier rather than deleting
> it. It might have saved you a lot of typing.
Yes, thanks to KJ for sharing the hard knocks.
> ... You get the worst
> of both worlds: archival issues, AND continual integration issues as you
> blindly track their updates. The soft-link at least allows you control
> over when you update the foreign source.
Since an svn copy is essentially free,
and since almost anything might be reused,
what is the downside to keeping all of
an organization's vhdl code in the same repository?
> It was a wise rule: NO FREAKING
> EXTERNALS. I've reaffirmed it with the thought exercise.
*Me too*, at least until I understand their upside.
-- Mike Treseler
MikeWhy
So... what are the benefits? If it's a single repository, I can see building
a virtual view of the tree, with just the parts I want, and arranged more
meaningfully in my local project. It makes sense sometimes to lift
libraries, say, so they are more accessible and visible, below the project
itself. That's not a problem for archiving, since they are snapped from the
same repository, with the same revision ids. In this case, you wouldn't lock
down the revisions unless you had a specific need for a particular revision.
Referencing a branch with the external probably makes as much or more sense
than explicitly tagging the external revision.
What about foreign repositories? The choices there are to import them into
your own repository. Leaving it as a foreign external, I would think you
want to lock down the revision.
KJ
>> It was a wise rule: NO FREAKING
>> EXTERNALS. I've reaffirmed it with the thought exercise.
>
> *Me too*, at least until I understand their upside.
>
One upside is that you don't have to try to remember on which project you
used 'widget' where you had made some improvement over the last time you
used 'widget'. All the reusable components would be in one place, a new
design project would simply svn_external reference them to get them into the
new design and then add new code for whatever is unique to the new design.
That way you don't have multiple similar (or the same) versions of 'widget'
around, just one, presumably the 'best' in that it has been refined over
time with various improvements.
The huge archive downside though makes svn_external something to be
extremely careful about ever using. The headache of manual revision
specification (and the potential to overlook at least one of them) is just
stupid.
KJ
Marcus Harnisch
Your "how-things-can-go-wrong" example is purely based on a work flow
that the inventors of SVN explicitly advise against.[1] It isn't as
hard as you make it look like.
Here's my interpretation of what you really want: Rather than having
to explicitly specifying revisions, Subversion ought to automatically
remember the current(?) state of any externally referenced
workspace. All metadata for doing this is available.
How's the system supposed to behave in different scenarios and how do
you specify the different behavior in each case?
Project1 -+- src
|
+- data
|
`-- Project2 [external reference]
1. Update Project1 workspace without also updating Project2 workspace,
because you really want to stick to one version of Project2 for the
time being.
2. Update Project1 workspace including updating Project2 workspace to
HEAD.
3. Update Project1 workspace including updating Project2 workspace to
a specific revision.
4. When you checkout a new working copy of Project1, which version of
Project2 will be used? HEAD, the one that was in the Project1
workspace that was last checked in or a specific revision? How much
work is involved tracking the actual changes (not just looking at
revision numbers) in Project2 since you last touched Project1? This
would be necessary to gain confidence you actually want that release.
Neither approach saves you from having to do this, but the argument
that having to explicitly specify a revision number makes things
considerably worse just doesn't hold any water.
Staying on top of all this involves much more work than adding an
explicit revision number to some text entry field. OIW, the extra
effort you complain about is neglectible in projects big enough to
make it worthwhile thinking about externals to begin with.
At least the Subversion externals mechanism lets everyone have her
way. I prefer that over tools that are trying to outsmart developers.
Lastly, you had doubts about your fellow co-workers being able to
properly maintain an externals property with revision numbers:
> How much effort do you think is worth expending to cover the
> omissions of others?
How about a trivial pre-commit hook checking that all externals have
explicit revision numbers. Which, BTW, could be -rHEAD, too. Which
shows another benefit: When I check out a working copy and get
Project2@HEAD I know that this is because sbdy explicitly wanted me to
get this and not because the tool happens to behave this way by
default.
Best regards
Marcus
Footnotes:
[1] "You should seriously consider using explicit revision numbers in all
of your externals definitions. [...]"
http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html
--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]
KJ
"Marcus Harnisch" <marcus....@gmx.net> wrote in message
news:87ab55x...@harnisch.dyndns.org...
> Hi KJ
>
> Your "how-things-can-go-wrong" example is purely based on a work flow
> that the inventors of SVN explicitly advise against.[1]
Marcus,
The workflow I suggested is an appropriate workflow if you have the
following goals in mind:
- You create modules intended to be reused, and...
- Those reusable modules get enhanced or changed over time, and...
- You need to be able to accurately reproduce all of the source files for a
particular build sometime in the future, and...
- You don't want to burden developers with a task that is easy to get wrong
or be incomplete
That SVN explicitly advises against it, simply indicates that those
developers do not have the above list of criteria in mind when they use SVN.
That's fine, they don't have to, others do though and other tools do support
that workflow.
One simple reason a supposedly 'reusable' module would change would simply
be because when it was first created and used, not necessarily every
optimization (or perhaps assertion checking) was put in. When you go to
reuse the module in some later design, you might improve it. That
improvement should propogate to all new users (i.e. checkouts from 'head')
but should never propogate to archival tags, ever.
Many developers don't meet the above criteria because
- They don't create reusable modules, they start from scratch or copy paste
snippets from here and there for every new design
- They create perfect reusable modules that can not possibly be improved on
- Never have to go back to investigate a problem peculiar to a particular
design that is not the current head revision.
- They have the time to burn having developers type in specific revision
numbers for each and every module (hoping they get every one of them) THEN
produce the final build for qualification testing. And have even more time
to do this whole exercise again for the next build that occurs the next
day...
> It isn't as hard as you make it look like.
>
In what way did I make it look harder than it is? I think I described the
steps accurately as well as describing the scenario and pressures that the
developers would be under at the particular time and the repercussions down
the road for making a bad move.
> Here's my interpretation of what you really want: Rather than having
> to explicitly specifying revisions, Subversion ought to automatically
> remember the current(?) state of any externally referenced
> workspace.
No, Subversion doesn't need to remember anything. It just needs to be able
to have a way to create a real archival tag. A reader of the Subversion
manual can be led to believe that doing the 'svn copy' thing to create a tag
does this, but in fact it doesn't if there is an svn_external with an
unspecified revision anywhere in the design. I'm not saying that what
Subversion has it wrong, just saying that it is missing a key piece if you
meet the criteria I outlined above. Google for svncopy.pl, find their
readme for more info on why you should be using that to create your archival
tags and not the native 'svn copy'
> All metadata for doing this is available.
>
That's possibly how svncopy.pl can perform it's magic.
> How's the system supposed to behave in different scenarios and how do
> you specify the different behavior in each case?
>
I think I described the different scenarios adequately in the previous
postings.
>
> Neither approach saves you from having to do this, but the argument
> that having to explicitly specify a revision number makes things
> considerably worse just doesn't hold any water.
>
Unless there is some very good reason (and there can be), I don't think
there should be any specific revision numbers called out for any
svn_externals that are referenced in the trunk or any code intended to be
merged back into the trunk in the future (i.e. any time you create new
code). The time when specific revision numbers should be added is when
you're creating an archival tag (i.e. a new build that will be tested). The
adding of those specific revision numbers during the creation of the tag
should be an automated process that replaces all unspecified revisions with
the current (head) revision of whatever thing is being referenced by that
svn_external (regardless of whether that thing is in the same physical repo
or not). It should not be manual and subject to errors.
If you have only one svn_external reference in your design, you can probably
handle this without much trouble. If you're really reusing modules though,
I'd wager that you have a lot more than that. Whether you think that is
'considerably worse' or not probably depends directly on whether or not
you've ever been on the back end and had to recreate the source to
investigate some problem on an old design.
> Staying on top of all this involves much more work than adding an
> explicit revision number to some text entry field. OIW, the extra
> effort you complain about is neglectible in projects big enough to
> make it worthwhile thinking about externals to begin with.
>
We'll just have to disagree on this point, 'specially when you're talking
about big projects.
> At least the Subversion externals mechanism lets everyone have her
> way. I prefer that over tools that are trying to outsmart developers.
>
Again, I never asked SVN to outsmart anyone. I'm just saying that it
doesn't natively provide a way to handle the workflow I mentioned (which is
OK) but it also tends to mislead one into thinking that it is correctly
archiving (which is not OK). The fact that svncopy.pl picks up the slack is
great...now if someone could fix svncopy.pl so that IT always worked.
> Lastly, you had doubts about your fellow co-workers being able to
> properly maintain an externals property with revision numbers:
>
>> How much effort do you think is worth expending to cover the
>> omissions of others?
>
> How about a trivial pre-commit hook checking that all externals have
> explicit revision numbers. Which, BTW, could be -rHEAD, too.
As I said, specific revision numbers for the most part should not be
commited. It's when you want to create an archival copy (i.e. a new build
to test) that they are needed. As for the pre-commit hook...so, if the tool
can't do what it should be capable of doing, then create a nag message? We
think differently on that point I guess.
Kevin Jennings
MikeWhy
>
> Many developers don't meet the above criteria because
> - They don't create reusable modules, they start from scratch or copy
> paste snippets from here and there for every new design
> - They create perfect reusable modules that can not possibly be improved
> on
> - Never have to go back to investigate a problem peculiar to a particular
> design that is not the current head revision.
> - They have the time to burn having developers type in specific revision
> numbers for each and every module (hoping they get every one of them) THEN
> produce the final build for qualification testing. And have even more
> time to do this whole exercise again for the next build that occurs the
> next day...
Wow. That's a mouthful of disdain. How about: I don't have time for
externals and have successfully avoided needing them. Not because we don't
reuse modules. The opposite is true. We've learned to reference them in
place.
Mike Treseler
> One upside is that you don't have to try to remember on which project you
> used 'widget' where you had made some improvement over the last time you
> used 'widget'. All the reusable components would be in one place, a new
> design project would simply svn_external reference them to get them into the
> new design and then add new code for whatever is unique to the new design.
> That way you don't have multiple similar (or the same) versions of 'widget'
> around, just one, presumably the 'best' in that it has been refined over
> time with various improvements.
>
> The huge archive downside though makes svn_external something to be
> extremely careful about ever using. The headache of manual revision
> specification (and the potential to overlook at least one of them) is just
> stupid.
I will stick with tagging my own reusable
vhdl library units and keeping all vhdl code in one repos.
The svn users know not to update a tags directory
even if they don't bother with formal reuse.
If a tag update does happen, there is an audit trail.
Upsides:
-If I update a library unit, I just copy a new tag.
-All changes are observable.
-No fussing with externals.
-Disinterested developers are not burdened by my reuse.
Downsides:
-No formal reuse enforcement or marketing.
-Interested developers might reinvent the wheel.
-- Mike Treseler
Marcus Harnisch
> "Marcus Harnisch" <marcus....@gmx.net> wrote in message
> news:87ab55x...@harnisch.dyndns.org...
>>
>> Your "how-things-can-go-wrong" example is purely based on a work flow
>> that the inventors of SVN explicitly advise against.[1]
>
> That SVN explicitly advises against it, simply indicates that those
> developers do not have the above list of criteria in mind when they use SVN.
> That's fine, they don't have to, others do though and other tools do support
> that workflow.
Sorry, my mistake. What I meant was not your workflow per se, but the
fact that externals references be used without explicit version
number.
>> It isn't as hard as you make it look like.
>>
> In what way did I make it look harder than it is? I think I described the
> steps accurately as well as describing the scenario and pressures that the
> developers would be under at the particular time and the repercussions down
> the road for making a bad move.
Sure you did. But as you wrote in that same message, you chose not to
put a revision number in the externals property, despite the fact that
you were aware of the issue. I guess you could say that your provoked
the result.
> No, Subversion doesn't need to remember anything. It just needs to be able
> to have a way to create a real archival tag.
But it would help you, I think. First of all, in SVN there is no such
thing as an archival tag. *Every* revision is one implicitly. I know
that other tools treat archiving specially but SVN doesn't. That's one
reason why it is so simple. If Subversion automatically remembered the
current revision of a checked out sub-project Project2 when you commit
Project1, you would be able to restore the exact state of Project1 at
any time, no?
Thinking about it, I suppose you could come up with a pre-commit (or
perhaps start-commit) script, that scans your externals property and
updates revision tags for all sub-projects.
> A reader of the Subversion manual can be led to believe that doing
> the 'svn copy' thing to create a tag does this.
Hardly.
> Google for svncopy.pl, find their readme for more info on why you
> should be using that to create your archival tags and not the native
> 'svn copy'.
Hmm, half of the job of svncopy.pl (absolute paths) has been obsoleted
by changes in SVN's externals syntax. This wouldn't apply to me
personally anyway, since I prefer using separate repositories for
projects.
The other half (maintaining the externals revisions) could be handled
by a hook (see above), so that users don't even have to worry about this.
> Unless there is some very good reason (and there can be), I don't think
> there should be any specific revision numbers called out for any
> svn_externals that are referenced in the trunk or any code intended to be
> merged back into the trunk in the future (i.e. any time you create new
> code). The time when specific revision numbers should be added is when
> you're creating an archival tag (i.e. a new build that will be tested). The
> adding of those specific revision numbers during the creation of the tag
> should be an automated process that replaces all unspecified revisions with
> the current (head) revision of whatever thing is being referenced by that
> svn_external (regardless of whether that thing is in the same physical repo
> or not). It should not be manual and subject to errors.
Since "archival tags" are not part of the SVN concept, here is how it
might work. Given a hook script as described above, you may settle on
a repository structure similar to the quasi standard "trunk, branches,
tags". The proposed hook could fix the externals revisions whenever
you are about to commit something into "tags". Commiting to other
directories would not touch your revision-less externals property.
> As I said, specific revision numbers for the most part should not be
> commited.
The revisions information about your "archival tag" has to be stored
somwhere. Whether automatically managed or not, it *has* to be
committed.
Regards
Marcus
Andy Peters
> I wish I had sent the <AOL>Me too!</AOL> earlier rather than deleting it. It
> might have saved you a lot of typing. Fundamentally, I agree with your
> observation, that svn:externals have archival problems. But I come to a
> different conclusion. If you need to use them, the externals must all have
> explicit revision references. Otherwise, they are little more useful than
> `ln -s` soft links to a local working copy of the foreign repository. In
> fact, they are worse in some respects. You get the worst of both worlds:
> archival issues, AND continual integration issues as you blindly track their
> updates. The soft-link at least allows you control over when you update the
> foreign source.
If you consider that your subproject modules -- the things you would
include in a larger design using externals -- can be tagged, then
simply adopt the paradigm that tags are immutable. For released
designs you should always use a tagged version of the module, never
the trunk. It's really pretty simple, and it works. There's no need to
keep track of which revision of the submodule (no need to deal with
pinned revisions), and as noted, the svn copy you do to make the tag
is "cheap."
Really -- it works.
-a
KJ
>
> If you consider that your subproject modules -- the things you would
> include in a larger design using externals -- can be tagged, then
> simply adopt the paradigm that tags are immutable.
I'm not sure I follow what you're saying. Creating a tag does not
make the tag immutable, nor do I get how one would "adopt a pardigm"
that it is (although I absolutely agree that the thing that is tagged,
and all of the things it references, if any, 'should' not be
changable). The tag simply indicates the revision level of the
repository of a particular project (i.e. the top level of the design)
> For released
> designs you should always use a tagged version of the module, never
> the trunk.
I agree, create the tag and build from that. But if you have an
svn_external with an unspecified revision anywhere then when you go to
retrieve the tagged item one year from now, you won't get the same
thing that you get if you retrieve it today if the thing that is
referenced via the svn_external happens to change between those two
times.
> It's really pretty simple, and it works. There's no need to
> keep track of which revision of the submodule (no need to deal with
> pinned revisions), and as noted, the svn copy you do to make the tag
> is "cheap."
>
> Really -- it works.
>
If so, then you should be able to complete steps 1 thru 16 from my May
20 post and then have an explanation as requested for step #17. So
far nobody has.
If there is some method to use Subversion to meet the following goals
(from the May 22 post) I'd like to hear it.
- You create modules intended to be reused, and...
- Those reusable modules get enhanced or changed over time, and...
- You need to be able to accurately reproduce all of the source files
for a
particular build sometime in the future, and...
- You don't want to burden developers with a task that is easy to get
wrong
or be incomplete
KJ
Charles Gardiner
Hi KJ,
I completely agree with Andy. It does work. The 'paradigm change' is in
step 4 of your May 20 post.
The steps are
1. Setup a new repository
2. Add new folders called 'Project1' and 'Project2' to the repo.
3. Export 'Project1' to some folder
4. Add the svn_external property to the working copy of 'Project1' to
reference 'Project2'.
4+ Do not use the working copy of Project2. Tag (svn copy) Project2
first. Reference this tagged version of Project2 in Project1.
Any further development to Project2 is done on the trunk. If you ever
find you have to change the version of Project2 in Project1, make a new
tagged version of Project2 first and change the svn:externals to
reference this.
Never ever import the _trunk_ of a sub project into a super-project. The
trunk is for development, tags are for releases.
I extracted one of my archived projects (about a year old) a few days
ago and it worked just as expected.
Regards,
Charles
KJ
"Charles Gardiner" <inv...@invalid.invalid> wrote in message
> 1. Setup a new repository
> 2. Add new folders called 'Project1' and 'Project2' to the repo.
> 3. Export 'Project1' to some folder
> 4. Add the svn_external property to the working copy of 'Project1' to
> reference 'Project2'.
>
> 4+ Do not use the working copy of Project2. Tag (svn copy) Project2
> first. Reference this tagged version of Project2 in Project1.
>
Step 4+ is essentially the same thing as referencing a specific revision of
Project2 in Project1. Either way, in order to prepare for a release
candidate build of Project1, one would have to manually make sure that each
and every revision reference points to the latest/greatest (or per your
suggestion, make sure that each sub-project tag is a copy of the
latest/greatest). I'm not saying that this method doesn't work, but (in my
opinion) violates the goal of
>> - You don't want to burden developers with a task that is easy to get
>> wrong or be incomplete
Compare this with VSS, in which the equivalent to the busy work of manual
revision checking is to simply label Project1, and then export it. Maybe we
just don't agree that the manual task of making sure that each and every
revision is up to date at the time when you need to create a release
candidate build is a burden, or that it could ever be done incorrectly (like
missing the last update to some module)
I had listed several goals, all of which *should* be achievable by a
revision control tool, but do not appear to be possible using SVN but can
with other tools. I'm not a big fan of creating extra manual tasks that can
be done wrong when working concurrently on a project.
Thanks for your input on how you do things.
KJ
Andy Peters
> On May 26, 4:02 pm, Andy Peters <goo...@latke.net> wrote:
>
>
>
> > If you consider that your subproject modules -- the things you would
> > include in a larger design using externals -- can be tagged, then
> > simply adopt the paradigm that tags are immutable.
>
> I'm not sure I follow what you're saying. Creating a tag does not
> make the tag immutable, nor do I get how one would "adopt a pardigm"
> that it is (although I absolutely agree that the thing that is tagged,
> and all of the things it references, if any, 'should' not be
> changable). The tag simply indicates the revision level of the
> repository of a particular project (i.e. the top level of the design)
By "paradigm" I suppose I really mean "common practice." And the
common practice with Subversion is that you never modify tags. If you
use TortoiseSVN, and you try to commit a change to a tag, TSVN will
complain. It's a kind of gentle reminder.
> > For released
> > designs you should always use a tagged version of the module, never
> > the trunk.
>
> I agree, create the tag and build from that. But if you have an
> svn_external with an unspecified revision anywhere then when you go to
> retrieve the tagged item one year from now, you won't get the same
> thing that you get if you retrieve it today if the thing that is
> referenced via the svn_external happens to change between those two
> times.
That is NOT true. If no changes are committed to the tagged branch
(sorry for mixing svn metaphors here), and the whole point of keeping
tags is that you do NOT change them -- then you WILL get exactly what
you expect. Think of the tag as a mnemonic that refers to the state of
the repository at the time at which the tag was made. Why remember -
r45677 when instead you can remember tag\Release-v1.0.0?
> > It's really pretty simple, and it works. There's no need to
> > keep track of which revision of the submodule (no need to deal with
> > pinned revisions), and as noted, the svn copy you do to make the tag
> > is "cheap."
>
> > Really -- it works.
>
> If so, then you should be able to complete steps 1 thru 16 from my May
> 20 post and then have an explanation as requested for step #17. So
> far nobody has.
>
> If there is some method to use Subversion to meet the following goals
> (from the May 22 post) I'd like to hear it.
> - You create modules intended to be reused, and...
> - Those reusable modules get enhanced or changed over time, and...
> - You need to be able to accurately reproduce all of the source files
> for a
> particular build sometime in the future, and...
> - You don't want to burden developers with a task that is easy to get
> wrong
> or be incomplete
Tags do that! The changes to the reusable modules get made to those
modules' TRUNKS, never the tags.
And if you decide that you like a newer version of your foo module,
tag it as tags\Release-v2.0.0. If you check out any previous designs
that depended on Release-v1.0.0, you will in fact get the state of all
of that module's files as of the Release-v1.0.0 tag! The old tag is
never removed and never changed, and you can use either version as you
see fit.
I am not sure if I can explain this any better.
-a
KJ
"Andy Peters" <goo...@latke.net> wrote in message
news:8e00787a-9a21-40d4...@d19g2000prh.googlegroups.com...
On May 26, 2:22 pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On May 26, 4:02 pm, Andy Peters <goo...@latke.net> wrote:
>
> > > If you consider that your subproject modules -- the things you would
> > > include in a larger design using externals -- can be tagged, then
> > > simply adopt the paradigm that tags are immutable.
> >
> > I'm not sure I follow what you're saying. Creating a tag does not
> > make the tag immutable, nor do I get how one would "adopt a pardigm"
> > that it is (although I absolutely agree that the thing that is tagged,
> > and all of the things it references, if any, 'should' not be
> > changable). The tag simply indicates the revision level of the
> > repository of a particular project (i.e. the top level of the design)
>
> By "paradigm" I suppose I really mean "common practice." And the
> common practice with Subversion is that you never modify tags.
I agree, never modify tags...and if you look at my simple example of a usage
of svn_externals in my posting from May 20, in step 9 I said to create a
tag. In steps 10 thru 15 I made a change to the 'trunk' of 'Project2' and
when I re-exported the tag in step #15, I didn't get what was originally
tagged, 'Project2' had stuff from the trunk.
It's not totally clear to me why somebody would prefer such behaviour, and I
don't begrudge them having it if they so choose, but saying that you can
recover exactly what you originally tagged, just because you created a tag
and did not modify the tag is not really correct. You can only make that
statement if there are either no externals or every external is explicitly
revision specified.
> >
> > I agree, create the tag and build from that. But if you have an
> > svn_external with an unspecified revision anywhere then when you go to
> > retrieve the tagged item one year from now, you won't get the same
> > thing that you get if you retrieve it today if the thing that is
> > referenced via the svn_external happens to change between those two
> > times.
>
> That is NOT true. If no changes are committed to the tagged branch
> (sorry for mixing svn metaphors here), and the whole point of keeping
> tags is that you do NOT change them -- then you WILL get exactly what
> you expect.
If you really believe that then you should be able to explain why in my May
20 posting, I got different results from exporting the tag after modifying
only the trunk. The answer, quite simply, (and I knew this going in and you
probably do too) is that the different results from exporting an unmodified
tag are a result of the lack of a revision being specified...OK, so what
mechanism exists to lock down revisions at the time of tag creation?
svncopy.pl is the only mechanism I've run across, but it has problems as
well.
The other mechanism is to explicitly declare revision levels. If done
during concurrent development this task will hinder development since every
user of a widget will have to manually change the revision level in order to
get the latest/greatest from something that has already been tested and
commited by the developer. When it gets near time for product release, this
manual step is something again that can get in the way at a time when
developers are under pressure to get their last fixes in. Charles, in his
reply, suggested another step that gets around the problem, but is
essentially the same as simply locking down a revision (actually a slight
bit more work). Whether or not somebody thinks this cost is 'worth it' or
'not a big deal', is totally up to that person. It certainly appears though
to be extra effort needed so that you can use SVN, but with no real upside
(other than so you can continue to use SVN, or Tortoise...I do by the way).
I don't mind that SVN has 'cheap copies' that cut down on disk usage, but I
think it's an oversight on SVN's part that it doesn't also support a
mechanism to simply take a snapshot of a project (and it's sub-projects) and
lock down any revisions that are not specified. When I do a checkout or an
export, it tells me the revision of each external so it's not like it can't
be done. The fact that svncopy.pl exists at all suggests I'm not alone in
seeing this as something important (although I seem to be almost alone in
this particular newsgroup). I've posted to the Subversion group a (as have
others) and either nothing comes back, or in one case the repliers got
somewhat hostile for suggesting that SVN might be missing something. The
Tortoise newsgroup though seems to agree that this would be a good thing,
but basically thought that it is up to SVN to first provide the capability
so that Tortoise can take advantage of it.
> Think of the tag as a mnemonic that refers to the state of
> the repository at the time at which the tag was made. Why remember -
> r45677 when instead you can remember tag\Release-v1.0.0?
>
I agree.
> >
> > If there is some method to use Subversion to meet the following goals
> > (from the May 22 post) I'd like to hear it.
> > - You create modules intended to be reused, and...
> > - Those reusable modules get enhanced or changed over time, and...
> > - You need to be able to accurately reproduce all of the source files
> > for a
> > particular build sometime in the future, and...
> > - You don't want to burden developers with a task that is easy to get
> > wrong
> > or be incomplete
>
> Tags do that! The changes to the reusable modules get made to those
> modules' TRUNKS, never the tags.
>
I guess we disagree on this point. But if you can list a process that
really does meet all of the above mentioned goals I'd like to hear it.
> And if you decide that you like a newer version of your foo module,
> tag it as tags\Release-v2.0.0. If you check out any previous designs
> that depended on Release-v1.0.0, you will in fact get the state of all
> of that module's files as of the Release-v1.0.0 tag! The old tag is
> never removed and never changed, and you can use either version as you
> see fit.
>
I understand that and agree that the v1.0.0 tag will be retrieved under the
conditions you describe...but only if module 'foo' doesn't happen to have
any svn_externals in it. Now stand back for a moment and view your process
from the point of view of doing concurrent development where both the new
widget is being developed as well as the widget being integrated into a
design and evaluate it against these two particular points (which you've
already stated are handled by tags)
- Those reusable modules get enhanced or changed over time, and...
- You don't want to burden developers with a task that is easy to get wrong
or be incomplete
The time period over which the module changes can be short (it's under
development remember, we're not talking about the integration of a stable,
static design). What happens is the integrator is burdened with having to
update his links to point to a new tag, just so he can get the
latest/greatest. Before updating though, he is also burdened with simply
discovering that there is an updated version even available. Multiply that
effort by say 10 modules and again by 4 designs and several changes to
modules and the whole mess has to be released at the end of the month. Is
that really how you want your integrator spending their time? How about the
delay that is created because the integrator has to do this process for each
build...or does this get shortcut because the integrator 'knows' what things
have changed? How do you 'know' that he/she 'knows' and didn't miss
something? The integrator is also burdened with insuring that there are no
unspecified revisions on any externals that may be lurking in all modules
(on every build). The developer has the additional burden of creating a new
tag, as opposed to simply committing his change. How do you insure that
happens every time? How do you check to see that the repo is in that state
prior to a build?
I'm not necessarily expecting answers here to all this, just potential holes
that I see in your process that can only be fixed by manual
intervention...all because SVN doesn't natively support a method of
capturing a snapshot of the repo and being able to truly recreate it later
except under special conditions...conditions that cause more work.
From a more fundamental standpoint, you should always be able to answer
'yes' to the following questions:
- Is your build built from an unchangable tag? (I agree that your method
gets a yes)
- Is your tag built from a snapshot of the trunk? Given your process, you
would have to manually verify this by checking that the tag for each module
reflects what is in the trunk and then verify that the integration of each
module also points to this latest tag. Maybe you can automate this...if
it's not, you can't really guarantee this...you can only hope that mistakes
don't get made by mere mortals.
With my method of unspecified versions on externals, it exposes me only on
the archival front and none of the others. If some Perl wizard would fix
svncopy.pl, the archival hole could be closed as well (or of course, if SVN
added a new form of copy that locked down revisions to whatever they are at
the time that the copy is performed).
> I am not sure if I can explain this any better.
You don't have to, thanks for your explanation. I think you're overstating
a bit what tags really do because of the way you happen to choose to use
them. But because of the way you use them, you're exposed on a couple of
the points. You're maybe aware of them anyway, but it was a good
discussion...even if it really had no place in comp.lang.vhdl in the first
place. Apologies to those clv readers that found this boring and off topic.
Kevin Jennings
Mike Treseler
> You can only make that
> statement if there are either no externals or every external is explicitly
> revision specified.
And that is why I keep all referenced code
in the same repository and use no externals.
For me, externals are not worth all the brain cycles.
svn isn't perfect, but it works real good for free.
Andy Peters wrote:
>> Think of the tag as a mnemonic that refers to the state of
>> the repository at the time at which the tag was made. Why remember -
>> r45677 when instead you can remember tag\Release-v1.0.0?
KJ wrote:
> I agree.
Me too
> Apologies to those clv readers that found this boring and off topic.
I think the discussion is on-topic as
lack of proper version control is a significant
problem in vhdl projects with multiple developers.
-- Mike Treseler
Andy Peters
> "Andy Peters" <goo...@latke.net> wrote in message
> > That is NOT true. If no changes are committed to the tagged branch
> > (sorry for mixing svn metaphors here), and the whole point of keeping
> > tags is that you do NOT change them -- then you WILL get exactly what
> > you expect.
>
> If you really believe that then you should be able to explain why in my May
> 20 posting, I got different results from exporting the tag after modifying
> only the trunk. The answer, quite simply, (and I knew this going in and you
> probably do too) is that the different results from exporting an unmodified
> tag are a result of the lack of a revision being specified...OK, so what
> mechanism exists to lock down revisions at the time of tag creation?
> svncopy.pl is the only mechanism I've run across, but it has problems as
> well.
So you are saying that you:
a) Tagged a submodule,
b) Added the submodule tag to the main project's source directory,
c) Did an svn update on the main project's source directory,
d) Committed the change to the main project's source directory.
e) Later checked out or exported the main project and discovered that
the submodule had the wrong stuff in it?
OK, I went back and found the 19 May post that describes your issue:
> 1. Setup a new repository
> 2. Add new folders called 'Project1' and 'Project2' to the repo.
> 3. Export 'Project1' to some folder
> 4. Add the svn_external property to the working copy of 'Project1' to reference 'Project2'.
By "reference 'Project2'" here, I assume that you mean you are
referencing Project2's TRUNK and not a TAG?
> 5. Do an update to get Project2 into the working copy.
> 6. Create a new text file called 'Project2_File.txt' in the Project2 folder.
> 7. Edit Project2_File.txt so it has the single line of text 'This is line #1'
> 8. Add Project2_File.txt into 'Project2' and commit the changes to both 'Project1' and 'Project2'.
At this point, Project2's __trunk__ now has the file
Project2_File.txt. You point out that it is likely that you will be
simultaneously working on both Project1 and its submodule Project2,
and so the external pointing to Project2's __trunk__ is correct.
> 9. Create your tag of 'Project1' using 'svn copy' or TortoiseSVN so that you
> get the warm fuzzy feeling that you've successfully archived away the
> current state of 'Project1' at this moment in time confident that you can
> come back at any time to recover this entire project exactly as it was left
> after step #8. To do so you will of course be specifying the exact revision
> of 'Project1' to use to create the tag. Lets say this tagged version of
> 'Project1' is put into the archive at 'Tags/Project1_1.0'
********************************
And here is the problem:
You never created a tag for Project2.
********************************
The svn:externals property on Project1 probably looks like
Project2 svn://myrepo/Project2
So even though you created a tag for Project1, that tag still refers
to the head of Project2, and as such, if someone later modifies
Project2, you get those modifications, even though you checked out the
tagged version of Project1.
Project2 is its own project within the repo. So you will have to
create tags for it.
If you create a tag for Project2 (for example, Project2-v1.0), and
change the svn:externals property on Project1 to look like:
Project2 svn://myrepo/Project2/tags/Project2-v1.0/
then I __guarantee__ that this will work the way you want it to work.
---------------------------------------------
Assume that Project1 has two files, foo.txt and bar.txt, as well as
requiring the stuff in Project2. To ensure that we always get the
correct version of Project2, we've set the svn:externals property on
Project1 as noted above. Now we tag Project1 as Project1-v1.0. That
tag, which is a copy of Project1, also has the svn:externals property
referencing the tag Project2-v1.0.
So say we wish to check out the the Project1-v1.0 tag into the
directory /devel/Project1. Your working copy will look like:
/devel/Project1/ <- top of working copy
/devel/Project1/foo.txt <- a file in Project1
/devel/Project1/bar.txt <- another file in
Project1
/devel/Project1/Project2/ <- brought in by externals
/devel/Project1/Project2/Project2_File.txt <- the file in Project2
--------------------------------------------------------------------------
So your repo should be structured essentially like:
//myrepo/Project1/trunk <- working trunk for Project1
//myrepo/Project1/tags <- tags here
//myrepo/Project1/tags/Project1-v1.0 <- tag for 1st release
//myrepo/Project1/tags/Project1-v2.0 <- tag for 2nd release
//myrepo/Project2/trunk <- working trunk for Project2
//myrepo/Project2/tags <- tags here
//myrepo/Project2/tags/Project2-v1.0 <- tag for 1st release of
Project2
//myrepo/Project2/tags/Project2-v2.0 <- tag for 2nd release of
Project2
Does this help???
-a
Marcus Harnisch
> So even though you created a tag for Project1, that tag still refers
> to the head of Project2, and as such, if someone later modifies
> Project2, you get those modifications, even though you checked out the
> tagged version of Project1.
>
> Project2 is its own project within the repo. So you will have to
> create tags for it.
>
> If you create a tag for Project2 (for example, Project2-v1.0), and
> change the svn:externals property on Project1 to look like:
>
> Project2 svn://myrepo/Project2/tags/Project2-v1.0/
>
> then I __guarantee__ that this will work the way you want it to
> work.
No. Because that is not the way KJ wants it to work as far as I
understand it. While this is not my development style, I think this is
a perfectly valid request.
1. KJ wants to be able to check out Project1, which refers
Project2. Whenever Project1 is checked out, the most recent
revision of Project2 should be checked out into the subdirectory of
Project1.
2. While he is working on Project1, he occasionally updates the
Project2 subdirectory to stay up-to-date. At some point KJ wants to
take a snapshot of his Project1 workspace *including* the current
state of all externals (i.e. Project2). In order to do that,
Subversion requires you to put explicit revision numbers into
externals property, which means that upon the next check out of
Project1, that same revision of Project2 is checked ut as well. But
that's not what he wants (see 1.). He doesn't want to be bothered
with revision numbers just to create a (recreatable) snapshot of
the current state of his workspace.
To (sort of) support KJ's development style, Subversion gives you two
basic options:
*Don't* fix the externals revision number in main-line. Whenever you
are about to create a snapshot, you'd create a branch of Project1,
switch your workspace over to that branch, add the current revision
number of Project2 to the externals property and commit again. Create
a tag for that revision.
*Do* fix the externals revision number in main-line. Whenever you
check out Project1, you will get the same revision of Project2 that
was current last time Project1 was checked in[1]. In order to track
the latest releases of externals, go into each sub directory and do
'svn update'. Take note of the new revisions and keep the externals
property of Project1 in sync. This could easily be wrapped into a
script, I reckon.
Regards
Marcus
Footnotes:
[1] Or rather: last time you *didn't forget* to update the externals
property.
Charles Gardiner
>
> No. Because that is not the way KJ wants it to work as far as I
> understand it. While this is not my development style, I think this is
> a perfectly valid request.
>
> 1. KJ wants to be able to check out Project1, which refers
> Project2. Whenever Project1 is checked out, the most recent
> revision of Project2 should be checked out into the subdirectory of
> Project1.
>
> 2. While he is working on Project1, he occasionally updates the
> Project2 subdirectory to stay up-to-date. At some point KJ wants to
> take a snapshot of his Project1 workspace *including* the current
> state of all externals (i.e. Project2). In order to do that,
> Subversion requires you to put explicit revision numbers into
> externals property, which means that upon the next check out of
> Project1, that same revision of Project2 is checked ut as well. But
> that's not what he wants (see 1.). He doesn't want to be bothered
> with revision numbers just to create a (recreatable) snapshot of
> the current state of his workspace.
>
Hi,
from a work-flow view point, I see at least one major problem with this
methodology. If you are designing everything yourself in the course of
personal multi-tasking then it's fine, but as soon as a team is involved
I regard it as highly risky. The head should really carry the tag 'under
development'. I know several companies where the head is also used as a
sort of 'light-weight back-up'. A check-in is done on fridays, before
the developer goes on a course, holidays etc. and of course in larger
companies whenever the administrator needs to migrate the archive to a
different server (even if this is a seldom occurence). Also, it's very
useful to be able to check into the head from a workstation and pick it
up again from a lap-top when on the road and continue working.
Of course you could argue that the developer should make a branch first
and work there, merging back to trunk when he is finished. But this is
only forcing the responsibility on the developer of the reusable. The
flow is basically the same. You still need two 'streams' trunk/tags or
branches/trunk. I prefer the trunk/tags because it usually makes the
developer think of a tag name when he does the 'svn copy' even if it is
only 20090529a. But even that is better than simply 'r8080' or whatever.
An 'svn copy' to a tags or releases directory could be regarded as a
'contract'. The developer should be implicitly saying he has
fixed/improved/extended something, tested it and now makes it generally
available. IMHO, only reusables carrying this stamp should ever be
incorporated into a super-project.
Charles
KJ
"Charles Gardiner" <inv...@invalid.invalid> wrote in message
> Marcus Harnisch schrieb:
>
>>
>> No. Because that is not the way KJ wants it to work as far as I
>> understand it. While this is not my development style, I think this is
>> a perfectly valid request.
>>
>> 1. KJ wants to be able to check out Project1, which refers
>> Project2. Whenever Project1 is checked out, the most recent
>> revision of Project2 should be checked out into the subdirectory of
>> Project1.
>>
>> 2. While he is working on Project1, he occasionally updates the
>> Project2 subdirectory to stay up-to-date. At some point KJ wants to
>> take a snapshot of his Project1 workspace *including* the current
>> state of all externals (i.e. Project2). In order to do that,
>> Subversion requires you to put explicit revision numbers into
>> externals property, which means that upon the next check out of
>> Project1, that same revision of Project2 is checked ut as well. But
>> that's not what he wants (see 1.). He doesn't want to be bothered
>> with revision numbers just to create a (recreatable) snapshot of
>> the current state of his workspace.
>>
>
> Hi,
>
> from a work-flow view point, I see at least one major problem with this
> methodology. If you are designing everything yourself in the course of
> personal multi-tasking then it's fine, but as soon as a team is involved
> I regard it as highly risky.
Whether it's risky would depend on several other "usage-of-the-tool" factors
(more later), but I can say our software group has multiple people all
working concurrently and this is not an issue. However, they're also using
SourceSafe which then dictates a different type of work flow anyway, but the
bottom line is that when the integrator/builder person needs to create a
build they simply add a label to the top level project like
"xyz_Ver_1.0.10", then they check out that labelled version out and do their
build. I'm not trying to get into the relative merits/demerits of
SourceSafe versus Subversion here, my only points are:
- It is simple for the builder to create a new version that can then be
built
- There are no manual steps or checks that must be done to create the
labelled version, so there are no chances for mistakes when the those steps
get skipped. During crunch time, near product release, when time is very
valuable and scarce, the value of this probably should not be
underestimated.
- The build and test is a validation of what is in the trunk at a particular
moment. [1]
- That build can be recreated at any future time, regardless of what has
happened in the repository
> The head should really carry the tag 'under
> development'.
This seems to be an area where we differ somewhat. While I agree it is the
'under development' area, I don't think it should be used as scratch pad,
commits to the trunk should be understood to be contributing to the
development and should not 'break the build' or cause a test failure.
> Also, it's very
> useful to be able to check into the head from a workstation and pick it
> up again from a lap-top when on the road and continue working.
>
That would be a misuse of commits in my opinion. It's just as easy to
create a patch file and put the patch on the laptop, no commits are
necessary to handle this situation.
> Of course you could argue that the developer should make a branch first
> and work there, merging back to trunk when he is finished.
That would be the other way to do it. For the 'pick it up on the laptop
later' scenario that you just described, the branch/merge would probably not
be a very good way for the developer to handle the situation, that's one
thing that patches are good for. For an extended development branch/merge
makes more sense. The point of creating the branch in the first place is to
totally decouple the widget from the trunk for the time being. It creates a
private work area for the developer...for now.
> But this is
> only forcing the responsibility on the developer of the reusable.
Since the developer is making the changes, this is where the responsibility
belongs.
Shoving the responsibility to each integrator to discern when the changes
are completed (what notifies them to do this) and then make possibly
numerous changes (i.e. to update all of his references to any newly changed
things) and putting this task on the critical path to the build (since the
task of updating those references can not even be started until after all
the developers creates their new tags) at a time of high stress (getting the
new build to fix the last problem/problems) is potentially error prone.
>
> An 'svn copy' to a tags or releases directory could be regarded as a
> 'contract'. The developer should be implicitly saying he has
> fixed/improved/extended something, tested it and now makes it generally
> available. IMHO, only reusables carrying this stamp should ever be
> incorporated into a super-project.
>
Contracts involve agreement between at least two parties and in this
instance (the creation of a new tag by a developer) there appears to be only
one, the developer. The creation of the new tag by a developer is not
anything the integrator would willingly agree to (but it is something that
can of course be imposed on them by local custom on how the version control
tool should be used). What it means to the integrator is that they must now
go in and update any references to the old thing that the developer made and
have it now point to the new thing. Multiply this task by having several
developers working on their own widgets and the integrator being responsible
for producing several different product builds and you quickly have a
potential mess...and ticked off integrator(s) who will greet each change as
an onerous burden rather than a relatively straight forward thing to handle.
Instead if the contract between integrator and developers is that things are
only committed to the trunk when they are "fixed/improved/extended" then the
integrator's work is straight forward, create a snapshot of the trunk (i.e.
create a release tag) and build it. Doing so has the following benefits:
- You haven't burdened the integrator to make changes in their stuff simply
to accomodate a new commit by a developer.
- You lessened the burden on the developer, there is no need for them to
create a new tag to follow the commit that they just did.
- You've lessened the need for problematic communication by the developer
announcing the availability of their new widget since now the developer does
not need to keep track of who all the integrators that might choose to use
their widget.
- The trunk then is the one place where one needs to go in order to get the
absolute latest/greatest/believed-to-be-best
Now of course the usual objection to this approach is that if the trunk is
the 'golden code' and a developer commits something that has some problem
with it then they've created a problem that needs to be fixed. OK, but the
problem exists, it is checked in, it needs to be fixed. With the approach
that you subscribe to, the developer has announced his new widget, the
integrator(s) cheerfully updates all of their references to the new widget,
does the builds and low and behold you're in the same spot, there is a
problem that needs fixing.
The only way you avoid having the problem appear is because of a breakdown
in communication between developer and integrator where the integrator was
unaware of the new widget and didn't update their references. Counting on a
breakdown in your system is probably not a 'good' thing to rely on. Finding
problems in the trunk early is better than finding them later. At crunch
time, if the problem can not be easily fixed, the integrator can choose to
roll back to the previous version by updating the references to widget to
point to the earlier working version. The solution and effort for this work
around is the same whether you follow my approach or yours, in my case
though this effort is the exception rather than standard operating
procedure.
Thanks again for explaining how you go about doing things, it's always good
to hear about different ways of approaching the same basic problem.
Kevin Jennings
[1] The assumption heres are that
- Trunk code that references reusable components does so via references to
components that do NOT specify specific revision levels (this would have to
be manually checked by the integrator, but also can be automated somewhat
and does not need to be a critical path thing to do)
- The creation of the tag or labelled version locks down specific revision
levels for that tag, but not to references that may be the trunk