You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Joachim Wingartz <j....@btp-aachen.DE> on 2005/03/10 10:37:29 UTC
2 questions about subversion usage
Good morning,
we have installed Subversion 1.1.1 and TortoiseSVN 1.1.1 in December 2004 in
order to check it out. In less than a month we found it to be 100% stable
and providing all features we need for version control of our software
development. Meanwhile more than 5000 source files (resulting in more than
800 executables and dll's) are located within a subversion repository. We
did not have one second of system downtime until now and you should be very
proud about your work!
Here are my questions:
We are using a Windows 2003 server where the subversion repository is
located and Windows NT4, Windows 2000 clients:
1.) When checking out a working copy all files have dates and times set to
the present date and time. Is there any way to maintain the original file
date and time?
2.) There are a couple of binary files (*.exe and *.dll program files) which
are committed to a second auxiliary subversion database. These files are
frequently recompiled from several places in order to provide proper
debugging information. As a result we get conficts against this repository.
Is there any way to disable conflict checking for a repository, for binary
files or ...?
Best regards
Joachim Wingartz
BTP Partner für Banktechnologie GmbH
Wilhelmstr. 29
D-52070 Aachen
Tel.: +49-241-94636-0
Fax.: +49-241-94636-50
E-Mail: j.wingartz@btp-aachen.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2 questions about subversion usage
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 10.03.2005, at 11:37, Joachim Wingartz wrote:
> 1.) When checking out a working copy all files have dates and times
> set to
> the present date and time. Is there any way to maintain the original
> file
> date and time?
I think you want "use-commit-times" which is described at the end of
this page:
http://svnbook.red-bean.com/en/1.1/ch07.html
I don't know the answer to your second question.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2 questions about subversion usage
Posted by ed...@fiserv.com.
If you're going to store a versioned copy of your compiled code, access to
this should at the very least be restricted to one or two people.
I wouldn't store this at all in your database - put it on your filesystem.
Edward Wittmann
Ben Collins-Sussman <su...@collab.net> wrote on 03/11/2005 02:35:09 PM:
>
> On Mar 10, 2005, at 4:37 AM, Joachim Wingartz wrote:
> >
> > 2.) There are a couple of binary files (*.exe and *.dll program files)
> > which
> > are committed to a second auxiliary subversion database. These files
> > are
> > frequently recompiled from several places in order to provide proper
> > debugging information. As a result we get conficts against this
> > repository.
> > Is there any way to disable conflict checking for a repository, for
> > binary
> > files or ...?
> >
>
> If every user is creating these objects, why are they under version
> control at all?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2 questions about subversion usage
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 10, 2005, at 4:37 AM, Joachim Wingartz wrote:
>
> 2.) There are a couple of binary files (*.exe and *.dll program files)
> which
> are committed to a second auxiliary subversion database. These files
> are
> frequently recompiled from several places in order to provide proper
> debugging information. As a result we get conficts against this
> repository.
> Is there any way to disable conflict checking for a repository, for
> binary
> files or ...?
>
If every user is creating these objects, why are they under version
control at all?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2 questions about subversion usage
Posted by Daniel Patterson <da...@danpat.net>.
Aaron Hilton wrote:
> Hi Daniel,
>
> I don't mean to sound too harsh, it's just a pet peeve, and I really
> like what SVN can already do.
>
> Anyway, loading a file by using "svn import" with a --replace variant
> would have its benefits too.
> But, I just want to say:
> svn commit -m "I don't care there was a change, just use this one
> instead." --force thisfile.bin
>
> In your oppinion, is this difficult to implement?
Ah, I think I understand what you're looking for, and it's a little
different to what I was thinking of.
You'd like something like:
svn update --dont-conflict-and-keep-my-changes (there's got to be
a better string than that)
or
svn commit --ignore-out-of-dateness
I have to say, while I can kind of understand where you're coming from
on that, I don't think it's such a great idea. In a busy environment,
you probably wouldn't want an option like that available. There has
been a lot of work put into Subversion to ensure that you can't
unknowingly discard someones changes.
If you implement a feature like this, then you might not replace the
file you think you're replacing. If someone slips in a commit
between when you looked at the repository, and when you commit,
you'd replace their changes and not even realise. That's what the
up-to-dateness check before a commit is all about. However, I'm
sure you realise that :-)
I think that the features I outlined above wouldn't be that hard
to implement (they're basically just optionally turning off some of
the consistency checking that's done right now). I don't think
it's a good idea personally.
As to whether it'd get into the codebase if a patch was submitted,
well, you'll have to ask on the dev@ list :-)
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2 questions about subversion usage
Posted by Aaron Hilton <vi...@shaw.ca>.
Hi Daniel,
I don't mean to sound too harsh, it's just a pet peeve, and I really
like what SVN can already do.
Anyway, loading a file by using "svn import" with a --replace variant
would have its benefits too.
But, I just want to say:
svn commit -m "I don't care there was a change, just use this one
instead." --force thisfile.bin
In your oppinion, is this difficult to implement?
- Aaron.
On Mar 12, 2005, at 4:32 PM, Daniel Patterson wrote:
> Aaron Hilton wrote:
>> That leads me to a little pet peeve here though... Can we not have
>> "FORCE" a part of svn commit? ? ? Come on guys! It's really useful
>> to just "man handle" the repository sometimes. I find doing a
>> temporary move, update, and overwrite to be a really pedagogical way
>> of forcing a commit. Of which really sucks for "getting the job
>> done."
>
> I think what you're talking about is a feature that I've been mulling
> over in my head for a while, trying to work out the best way to
> implement it.
>
> That is, add a "--replace" flag to "svn import", allowing you to
> blindly import stuff over the top of what already exists in the
> repository, without having to have a working copy. Kind of like
> moving the functionality of "svnloaddirs.pl" right into the svn
> client.
>
> It's relatively straightforward, but a non-trivial amount of work
> to implement (I'm sure someone more familiar with the commit editor
> would be able to whip it up in no time).
>
> daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2 questions about subversion usage
Posted by Daniel Patterson <da...@danpat.net>.
Aaron Hilton wrote:
>
> That leads me to a little pet peeve here though... Can we not have
> "FORCE" a part of svn commit? ? ? Come on guys! It's really useful to
> just "man handle" the repository sometimes. I find doing a temporary
> move, update, and overwrite to be a really pedagogical way of forcing a
> commit. Of which really sucks for "getting the job done."
I think what you're talking about is a feature that I've been mulling
over in my head for a while, trying to work out the best way to
implement it.
That is, add a "--replace" flag to "svn import", allowing you to
blindly import stuff over the top of what already exists in the
repository, without having to have a working copy. Kind of like
moving the functionality of "svnloaddirs.pl" right into the svn
client.
It's relatively straightforward, but a non-trivial amount of work
to implement (I'm sure someone more familiar with the commit editor
would be able to whip it up in no time).
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2 questions about subversion usage
Posted by Aaron Hilton <vi...@shaw.ca>.
Lets see if I can recapture what you're trying to do:
- You have a machine (or two) creating debug builds of those binaries
on a regular basis.
- Those builds are committed to an auxiliary svn repository.
- You're trying to merge the auxiliary repository against your active
repository only on 'good' builds?
This seems more suited to using TAGS as part of your repository
checkout routine. Only 'tag' good builds, and have your developers
pull from the 'TAGS' hierarchy yet still on the auxiliary svn
repository. I don't know if you can do this, but I would try to
side-step trying to force a merge onto another repository.
That leads me to a little pet peeve here though... Can we not have
"FORCE" a part of svn commit? ? ? Come on guys! It's really useful to
just "man handle" the repository sometimes. I find doing a temporary
move, update, and overwrite to be a really pedagogical way of forcing a
commit. Of which really sucks for "getting the job done."
- Aaron.
On 10-Mar-05, at 2:37 AM, Joachim Wingartz wrote:
> 2.) There are a couple of binary files (*.exe and *.dll program files)
> which
> are committed to a second auxiliary subversion database. These files
> are
> frequently recompiled from several places in order to provide proper
> debugging information. As a result we get conficts against this
> repository.
> Is there any way to disable conflict checking for a repository, for
> binary
> files or ...?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org