On Thu 2004-11-25 at 12:11:18 +0530, you wrote
> My repository contains source code of several packages. Some of the
> files are shared. An example:
> When I build a package, I like to tag the files of that specific
> package only. This way, when there is a problem between two versions
> of a package, the changes between the two versions can be reviewed.
> Something like:
> svn diff $REPOS/tags/pkg1-v100 $REPOS/tags/pkg1-v101
> Now, here if I tag the whole repository,
> a) the above diff will contain changes to files not in that package.
> This makes reviewing the changes difficult.
> b) changes in the filelist of the package are not visible. For
> example, if I add/delete files to/from a package (but not necessarily
> to/from the repository!), the above diff will not indicate the change
> in package filelist.
> Please help me on this. Is there a better way to achieve this?
You can prepare a working copy to represent what you want to be tagged
and then tag the working copy. That should handle both cases, a) and
b) fine. Would that work for you?
In more detail: for the above example, you would checkout your
repository, which gives:
Then you remove (*not* "svn rm"!) the unwanted file: include/b.h and
lib/b.c. That leaves
which is pkg1. Then you do the tagging like this (I never actually
tried this, so please verify that it fits your case):
svn copy . REPOS/tags/pkg1-v100
Done. You can either throught the working copy away or get back a full
working copy by svn update. If you repeat the same procedure in order
to tag REPOS/tags/pkg1-v101, then
svn diff $REPOS/tags/pkg1-v100 $REPOS/tags/pkg1-v101
should do what you expect (so long as I understood correctly what you
Of course, splitting up the packages in pkg1, pkg2 and pkg-common
might be the better long-term solution.
> [PARTLY OFFTOPIC:
> I also tried keeping the filelist of a package in a separate file and
> then monitoring the changes. Something like:
> svn diff -r20020:20024 $( cat file-containing-filelist-of-pkg1 )
> Unfortunately, this command causes the repository to partly crash when
I think on these lists the term "wedged" is preferred for situations
where the data itself is safe, but the meta-data (db-locks, logfiles,
etc) have trouble.
> the package contains more than 60 files or so. I have already reported
> this problem for 1.1.0, but there was no relevant response on this.
Hm. "Cannot allocate memory" is a bad error text from BDB. It rather
means "out of resources" as you get the error when BDB runs out of
locks, too. The second email seems to confirm this.
I don't actually know how it works, but it kinda sounds as if svn diff
tries to access all specified files in one sweep (transaction), only
releasing the resources properly when the program ends. The output in
the last email looks a lot like this. After fixing the first symptom
you are now running out of file descriptors, but the real problem is
that the resources are not freed in between diff's.
Here is another email that talks about DB_CONFIG values. I doubt this
helps in your case, but for reference it might be nice (especially
because it links to the man page for the config values):
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Nov 25 22:35:50 2004