You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Manuel VACELET <ma...@st.com> on 2004/11/25 12:59:17 UTC
svn copy and timestamp
Hi all,
Is it possible to make 'svn copy' with files timestamp preservation?
Regard,
Manuel
--
# VACELET Manuel manuel.vacelet-abecedaire(at)st(dot)com #
# Tel: 042 6089 +33 (0)476 92 6089 #
# STMicroelectronics - Central R&D DAIS - Flexware #
# 850, rue Jean Monet - 38926 CROLLES CEDEX - FRANCE #
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn copy conflicts with autotools ?
Posted by Leonardo Boiko <le...@conectiva.com.br>.
Eric PAIRE wrote:
> The problem is that all the dates of the checked out files have been
> modified,
> and when running 'make', the first thing run is 'autoconf' and
> 'automake', thus
> modifying source directory files (configure, ...).
You seem to keep generated files like "Makefile" and "configure" in the
repository. We follow a different approach; no generated files are
versioned, not even auxiliary scripts. A developer who wants to compile
from repository should have the correct autotoolset version and run
"autoreconf -ifs" and "configure" first.
This is what a svn:ignore looks like for a typical top_srcdir:
autom4te.cache
build
Makefile.in
configure
aclocal.m4
config.h.in
aux
Note that we usually build from the "build" subdirectory, not directly
from top_srcdir, and that auxiliary files like "config.guess" are kept
in "aux".
If a developer wants to compile without using autotools, he should use a
distribution tarball (generated by "make dist"), not the subversion sources.
It works :)
--
Leonardo Boiko
Re: svn copy conflicts with autotools ?
Posted by Eric PAIRE <er...@st.com>.
Hello Gary,
Gary Thomas wrote:
>Bonjour, Eric :-)
>
>On Wed, 2004-12-01 at 04:38, Eric PAIRE wrote:
>
>
>>Hi all,
>>
>>Here is the description of a problem met with subversion and autotools.
>>If anybody has a clean solution, let me/us know:
>>
>>1) I have a project using the autotools for the environment management.
>>2) The project compiles without any problem in the 'trunk' directory.
>>3) I have set up a tag with 'svn copy' so that the tagged version is the
>>exact
>> copy of the version in the 'trunk' directory.
>>4) Another user gets the tagged version with a 'svn co' and runs 'configure'
>> on it. And now ...
>>
>>The problem is that all the dates of the checked out files have been
>>modified,
>>and when running 'make', the first thing run is 'autoconf' and
>>'automake', thus
>>modifying source directory files (configure, ...). It was even worst in
>>our case, as
>>the autotools installed on the machine were too old and 'make' stopped
>>without
>>having built anything :-( :-( The result is that checking out a tagged
>>version may
>>lead to an unusable source tree (at least a tree needing some source
>>file modifications).
>>
>>This is the reason why I don't think it is a good thing that the
>>subversion philosophy
>>of timestamps conflicts with autotools one. I am looking for a solution
>>that would
>>allow a checkout to avoid rebuilding source files when not necessary.
>>Timestamps
>>need to be preserved somewhat, and I think that the way subversion
>>manages currently
>>timestamps should be coherent with autotools (or autotools should be
>>modified to
>>handle subversion philosophy), and in particular when doing a 'svn copy'.
>>
>>Thanks for your comments (and your solutions),
>>Eric PAIRE
>>
>>
>
>Doesn't setting "use-commit-times = yes" in your local configuration
>file (~/.subversion/config) solve this? The files will have the
>timestamp of when you committed them last when you check them out.
>Thus, you set them up and commit them to the trunk. All is well with
>the auto-tools. Then copy to your branch/tag. When you check them out
>you'll get the same timestamp if as when you committed them if you have
>this option set.
>
>
>
Unfortunately, I tried this feature, and it does not solve easily my particular
problem : I need to run multiple 'svn commmit' in order to respect modification
time of all the tools generated which means multiple 'svn copy' in the right
order when tagging a version (a real pain for doing a simple tag :-(
For now, the best existing solution is to not commit autotools generated files
under source control (which makes sense), and to regenerate them inside a
'svn export' tree. But what keeps on puzzling me with this solution is that
you need to modify the source tree of what you 'svn co' in order to be able to
use the package delivered.
Probably the right solution would be to modify the autotools to only get in the
source tree a generic 'configure' able to generate at the very beginning all
autotools files in the object tree without having to modify anything in the
source tree.
It remains clear that autotools and subversion are somewhat in conflict that
should be clearly fixed by both sides, saying what is the solution that is
jointly recommended.
Best regards,
Eric
Re: svn copy conflicts with autotools ?
Posted by Gary Thomas <ga...@mlbassoc.com>.
Bonjour, Eric :-)
On Wed, 2004-12-01 at 04:38, Eric PAIRE wrote:
> Hi all,
>
> Here is the description of a problem met with subversion and autotools.
> If anybody has a clean solution, let me/us know:
>
> 1) I have a project using the autotools for the environment management.
> 2) The project compiles without any problem in the 'trunk' directory.
> 3) I have set up a tag with 'svn copy' so that the tagged version is the
> exact
> copy of the version in the 'trunk' directory.
> 4) Another user gets the tagged version with a 'svn co' and runs 'configure'
> on it. And now ...
>
> The problem is that all the dates of the checked out files have been
> modified,
> and when running 'make', the first thing run is 'autoconf' and
> 'automake', thus
> modifying source directory files (configure, ...). It was even worst in
> our case, as
> the autotools installed on the machine were too old and 'make' stopped
> without
> having built anything :-( :-( The result is that checking out a tagged
> version may
> lead to an unusable source tree (at least a tree needing some source
> file modifications).
>
> This is the reason why I don't think it is a good thing that the
> subversion philosophy
> of timestamps conflicts with autotools one. I am looking for a solution
> that would
> allow a checkout to avoid rebuilding source files when not necessary.
> Timestamps
> need to be preserved somewhat, and I think that the way subversion
> manages currently
> timestamps should be coherent with autotools (or autotools should be
> modified to
> handle subversion philosophy), and in particular when doing a 'svn copy'.
>
> Thanks for your comments (and your solutions),
> Eric PAIRE
Doesn't setting "use-commit-times = yes" in your local configuration
file (~/.subversion/config) solve this? The files will have the
timestamp of when you committed them last when you check them out.
Thus, you set them up and commit them to the trunk. All is well with
the auto-tools. Then copy to your branch/tag. When you check them out
you'll get the same timestamp if as when you committed them if you have
this option set.
--
Gary Thomas <ga...@mlbassoc.com>
MLB Associates
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn copy conflicts with autotools ?
Posted by Sander Niemeijer <ni...@science-and-technology.nl>.
Hi all,
We had the same problems, so for the (re)bootstrapping of our project
we now use our own 'bootstrap' script (which is included in both CVS
and the source package):
---
#!/bin/sh
echo "---removing generated files---"
# products from ./configure and make
if test -f Makefile ; then
# touch all automatically generated targets that we do not want to
rebuild
touch aclocal.m4
touch configure
touch Makefile.in
touch config.status
touch Makefile
# make maintainer-clean
make -k maintainer-clean
fi
# products from autoreconf
rm -Rf autom4te.cache
rm -f Makefile.in aclocal.m4 compile config.guess config.sub configure \
config.h.in depcomp install-sh ltmain.sh missing py-compile ylwrap
if test "$1" != "clean" ; then
# bootstrap
echo "---autoreconf---"
autoreconf -v -i -f
fi
---
Feel free to use this as a template for your own project(s).
Best regards,
Sander Niemeijer
On donderdag, dec 2, 2004, at 10:31 Europe/Amsterdam, Eric PAIRE wrote:
>
> Bob Friesenhahn wrote:
>
>> On Wed, 1 Dec 2004, Eric PAIRE wrote:
>>
>>>
>>> It this solution is so obvious, I don't understand why autotools
>>> developers have not already set up a tool which automatically
>>> removes the files generated by the autotools (perhaps this tool
>>> exists and I don't know about).
>>
>>
>> It is called 'make maintainer-clean'. Unfortunately, if time stamps
>> are wrong, the Makefile may try to rebuild itself before executing
>> the target.
>>
> I tried this command, but it does not clean up all configure, stamp*,
> aclocal.m4, ... that was generated by the autotools.
> I guess that these must be removed by hand (or better ignored in the
> versioning system, if it is possible to get an
> exhausitve list of files generated).
>
> Eric
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn copy conflicts with autotools ?
Posted by Eric PAIRE <er...@st.com>.
Bob Friesenhahn wrote:
> On Wed, 1 Dec 2004, Eric PAIRE wrote:
>
>>
>> It this solution is so obvious, I don't understand why autotools
>> developers have not already set up a tool which automatically removes
>> the files generated by the autotools (perhaps this tool exists and I
>> don't know about).
>
>
> It is called 'make maintainer-clean'. Unfortunately, if time stamps
> are wrong, the Makefile may try to rebuild itself before executing the
> target.
>
I tried this command, but it does not clean up all configure, stamp*,
aclocal.m4, ... that was generated by the autotools.
I guess that these must be removed by hand (or better ignored in the
versioning system, if it is possible to get an
exhausitve list of files generated).
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn copy conflicts with autotools ?
Posted by Bob Friesenhahn <bf...@simple.dallas.tx.us>.
On Wed, 1 Dec 2004, Eric PAIRE wrote:
>
> It this solution is so obvious, I don't understand why autotools
> developers have not already set up a tool which automatically
> removes the files generated by the autotools (perhaps this tool
> exists and I don't know about).
It is called 'make maintainer-clean'. Unfortunately, if time stamps
are wrong, the Makefile may try to rebuild itself before executing the
target.
Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn copy conflicts with autotools ?
Posted by Henrique de Moraes Holschuh <hm...@debian.org>.
On Wed, 01 Dec 2004, Eric PAIRE wrote:
> everything, but you have to make these generated files ignored to your
> versioning
> system, and there should be a way to remove them easily.
Maybe one of the automake targets do a full cleanup, I never tried to track
that down. I never needed it. When I need a thruly pristine tree, I just
export one from the revision control system, since *no* autogenerated files
are in there at all. Docs you don't want changing under your feet such as
COPYING are under version control, of course. But autotools do not touch
that if it is already in place, so I don't think that counts for this
thread.
Anyway, I make sure to rm -f all autotools-generated files in the autogen.sh
script BEFORE I regen the autotools stuff (except for the docs, such as
COPYING, etc). This keeps stuff like install-sh always up-to-date ;-)
*AND* I make sure to get a properly up-to-date GNU config (config.sub and
config.guess) setup in at that time too, since THAT is a royal pain in the
ass.
> already set up a tool which automatically removes the files generated by
> the autotools
> (perhaps this tool exists and I don't know about).
Probably because you don't really need it most of the time, even if you keep
the autogenerated files outside of version control...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn copy conflicts with autotools ?
Posted by Eric PAIRE <er...@st.com>.
I already thought that this was the good solution, but I have always
been puzzled by
the fact that I never see it yet implemented (such as in gnu projects).
I agree on
everything, but you have to make these generated files ignored to your
versioning
system, and there should be a way to remove them easily.
It this solution is so obvious, I don't understand why autotools
developers have not
already set up a tool which automatically removes the files generated by
the autotools
(perhaps this tool exists and I don't know about).
Thanks,
Eric
P.S. The problem is less important with CVS, because CVS keeps
modification dates
(which generates others problems in the versioning system)
Henrique de Moraes Holschuh wrote:
>On Wed, 01 Dec 2004, Eric PAIRE wrote:
>
>
>>3) I have set up a tag with 'svn copy' so that the tagged version is the
>>exact
>> copy of the version in the 'trunk' directory.
>>4) Another user gets the tagged version with a 'svn co' and runs 'configure'
>> on it. And now ...
>>
>>
>
>As it was once so eloquently explained to me by a senior Debian developer
>when I asked exactly the same question (but for CVS, since Subversion didn't
>exist yet): "If you're doing that, you're weird. Go away".
>
>The translation for that would be: Why the heck are you keeping
>auto-generated files in a RCS system? Get them out of there, they do NOT
>belong in the repository!
>
>Add a run-this-on-checkout script and proper rules to the makefiles to run
>the autotools sequence if the autotools files are not yet available.
>
>As for a bad autotools setup on the build system, well, document properly
>what the build system has to have installed for the development versions.
>Anyone doing development has to be at least capable of a proper build system
>setup, no?
>
>When you generate a release, run autotools before you make a
>tar.bz2/tar.gz/.cab/whatever file that you're going to distribute. This
>way, all the autotools scripts are already built and have correct timestamps
>inside the distribution archive. Normal users won't need to bother with
>autotools configs, then, unless they muck with Makefile.am, configure.in or
>something else like that.
>
>
>
Re: svn copy conflicts with autotools ?
Posted by Eric PAIRE <er...@st.com>.
Bob Proulx wrote:
>Henrique de Moraes Holschuh wrote:
>
>
>>Add a run-this-on-checkout script and proper rules to the makefiles to run
>>the autotools sequence if the autotools files are not yet available.
>>
>>
>
>Shouldn't 'autoreconf' be the right answer to regenerate all of the
>autotools files after a clean checkout? Isn't that the tool designed
>to do the right thing to bootstrap the project?
>
>Bob
>
>
You're absolutely right, 'autoreconf' does the job. But IMHO, I think that
autotools should not generate anything in the source directory. Keep only a
generic configure in the source that will generate in a object directory all
the autotools files would be more appropriate, and there will be a clean
separation between generated and source files (and avoid any source tree
"pollution").
But I can live with this solution provided that I known all the files
generated by the autotools in each directory to put the coirrect subversion
'ignore' property.
Eric
Re: svn copy conflicts with autotools ?
Posted by Bob Proulx <bo...@proulx.com>.
Henrique de Moraes Holschuh wrote:
> Add a run-this-on-checkout script and proper rules to the makefiles to run
> the autotools sequence if the autotools files are not yet available.
Shouldn't 'autoreconf' be the right answer to regenerate all of the
autotools files after a clean checkout? Isn't that the tool designed
to do the right thing to bootstrap the project?
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn copy conflicts with autotools ?
Posted by Henrique de Moraes Holschuh <hm...@debian.org>.
On Wed, 01 Dec 2004, Eric PAIRE wrote:
> 3) I have set up a tag with 'svn copy' so that the tagged version is the
> exact
> copy of the version in the 'trunk' directory.
> 4) Another user gets the tagged version with a 'svn co' and runs 'configure'
> on it. And now ...
As it was once so eloquently explained to me by a senior Debian developer
when I asked exactly the same question (but for CVS, since Subversion didn't
exist yet): "If you're doing that, you're weird. Go away".
The translation for that would be: Why the heck are you keeping
auto-generated files in a RCS system? Get them out of there, they do NOT
belong in the repository!
Add a run-this-on-checkout script and proper rules to the makefiles to run
the autotools sequence if the autotools files are not yet available.
As for a bad autotools setup on the build system, well, document properly
what the build system has to have installed for the development versions.
Anyone doing development has to be at least capable of a proper build system
setup, no?
When you generate a release, run autotools before you make a
tar.bz2/tar.gz/.cab/whatever file that you're going to distribute. This
way, all the autotools scripts are already built and have correct timestamps
inside the distribution archive. Normal users won't need to bother with
autotools configs, then, unless they muck with Makefile.am, configure.in or
something else like that.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
svn copy conflicts with autotools ?
Posted by Eric PAIRE <er...@st.com>.
Hi all,
Here is the description of a problem met with subversion and autotools.
If anybody has a clean solution, let me/us know:
1) I have a project using the autotools for the environment management.
2) The project compiles without any problem in the 'trunk' directory.
3) I have set up a tag with 'svn copy' so that the tagged version is the
exact
copy of the version in the 'trunk' directory.
4) Another user gets the tagged version with a 'svn co' and runs 'configure'
on it. And now ...
The problem is that all the dates of the checked out files have been
modified,
and when running 'make', the first thing run is 'autoconf' and
'automake', thus
modifying source directory files (configure, ...). It was even worst in
our case, as
the autotools installed on the machine were too old and 'make' stopped
without
having built anything :-( :-( The result is that checking out a tagged
version may
lead to an unusable source tree (at least a tree needing some source
file modifications).
This is the reason why I don't think it is a good thing that the
subversion philosophy
of timestamps conflicts with autotools one. I am looking for a solution
that would
allow a checkout to avoid rebuilding source files when not necessary.
Timestamps
need to be preserved somewhat, and I think that the way subversion
manages currently
timestamps should be coherent with autotools (or autotools should be
modified to
handle subversion philosophy), and in particular when doing a 'svn copy'.
Thanks for your comments (and your solutions),
Eric PAIRE
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org