You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Ph. Marek" <ph...@bmlv.gv.at> on 2005/08/17 07:19:57 UTC
Re: Import and Commit and file modification times
On Wednesday 17 August 2005 08:42, Svante Seleborg wrote:
> Hello,
>
> Thank you for this answer.
>
> I'm not that keen on running off a special branch, it raises the barrier of
> entry pretty much - isn't there any plan to merge this into the mainline
> code?
>
> Also, I'm dependent on the .svn-workaround for Visual Studio it appears, so
> then I have two branches to consider when building.
>
> As far as I'm concerned it's a major "bug" in the design of SVN. I am once
> again missing something obvious such that there are major use-cases where
> such a merge would break something?
>
> I can't see the problem with supporting proper date-time stamps on files.
>
> Are there any plans to merge this with the mainline?
>
> Svante
http://marc.theaimsgroup.com/?l=subversion-dev&m=112418966912502&w=2
I've already discussed that several times ... the core developers seem not to
be interested.
But maybe if enough people complain ...
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Fwd: RE: Import and Commit and file modification times
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
As this mail doesn't seem to make it to the list I'm forwarding for Svante.
From: "Svante Seleborg" <sv...@axantum.com>
> Hello,
>
> I posted a long answer to this to the mailing list (and to you), but for
> some reason I can't subscribe to the list, so I don't get to see if it makes
> it to the list.
>
> If it doesn't can you please forward it there for me?
>
> Best regards,
>
> Svante
Here you are.
---------- Forwarded Message ----------
Subject: RE: Import and Commit and file modification times
Date: Wednesday 17 August 2005 10:19
From: "Svante Seleborg" <sv...@axantum.com>
To: "'Ph. Marek'" <ph...@bmlv.gv.at>, dev@subversion.tigris.org
To the developers of Subversion,
I'm an open source developer (axpipe and axcrypt.sf.net), wanting to migrate
from CVS.
Subversion has many advantages, and I'd like to thank you for all your
efforts and an excellent result made available to the community.
But, since I happen to do .NET-development as well I first of all need a
special build to work around some obscure Visual Studio-bug with directory
names beginning with "dot". This is sort of off-topic, but why on earth
can't this be made the supported behavior on the Windows platform, instead
of making a custom explicitly non-supported build? Just because Unix has a
long tradition of hiding directories starting with "dot" from casual view
(because of missing file-system features), why use that kludge on the
Windows platform which since the beginning of time has had that feature in
the file system in the form of the "hidden" file attribute??? Multi-platform
support includes adapting to the local system behavior. When in Rome, do as
the Romans do.
Now to the real issue.... ;-)
Most projects do not begin with a clean slate and an installation of
Subversion. Most of us have code that we want to start with, and import.
Part of that code consists of various meta information, such as the file
name and last time of modification (NOT last time of commit! - That is a
different story, and is about migration from one repository to another).
Unfortunately these two issues adds up to Subversion currently not being
such a totally compelling replacement for CVS as I'd like, and for many with
me apparently.
On a very fundamental basis, I think it's important to think about what a
repository and source code control system does, and should do. In my mind -
the operation sequence: Import - Checkout/Export should be a no-operation as
far as the sources involved are concerned - i.e. they should not be
modified!!!
If you don't change anything, you should always be able to take out exactly
what you put into the repository. Otherwise you loose information. Can
anyone even consider a backup-program which does not restore the filenames
and timestamps correctly, but instead substitutes the time of backup when
you restore? Granted, Subversion is not a backup program, but the
expectation is similar in this regard for most users.
I'm the one who should be modifying the sources - NOT the repository (unless
I specifically ask for it, for example by insertion of keyword
replacements). There's meta information in the repository, but that's a
different thing. It's kept by the repository, and should I ever want to
change repository that's a migration issue.
There are two fundamental pieces of meta information attached to source code
files, which are external to the actual text of the files and unrelated to
any repository:
1 - The file name
2 - The file modification timestamps
For some reason, Subversion is designed such that the file name should
remain unmodified by the repository, but the file modification timestamps
should not. Why?
Both the file name AND the timestamps are used by external processes to
control builds, affect the output, and should remain unchanged by the
repository!
Both the file name AND the timestamps are used by humans to understand the
structure and history of the sources.
It's no science fiction to imagine a scenario where the file names and the
timestamps are used both to control the actual build, and even are included
in the final output. Specifically - Subversion breaks my build system for
AxCrypt.
Subversion states: "The goal of the Subversion project is to build a version
control system that is a compelling replacement for CVS in the open source
community".
There are apparently quite a few open source developers who would prefer
that ALL of the external meta information of a file is maintained unmodified
by the repository, and apparently few who argue against it.
I'd like to make a strong case for Subversion to re-consider the current
stance on this issue.
There's even code available to implement it - or at least part of it, from
Philipp Marek. If that code, for whatever reason, is not acceptable to bring
into the mainline I'd be pleased to participate in the design and
development of this feature myself.
To summarize:
- There is obviously a significant part of the open source community
using/wanting to use Subversion who are negatively affected by two major
design decisions in Subversion - The .svn thing, and the timestamp issue.
- Subversion has as it's mission goal to attract users. This must reasonably
imply that users opinions are what counts! (I didn't write the mission goal
- but since it states what it does, a logical conclusion is that the voice
of the users is important.)
- Those same users even offer their time and help in good open source
community spirit.
- Let's just get this done with, so Subversion can become an even more
compelling replacement for CVS for more users, in more environments!
Best regards,
Svante
(snip - The apparently frequent question about original timestamp
preservation)
> > I'm not that keen on running off a special branch, it raises the
> > barrier of entry pretty much - isn't there any plan to
>
> merge this into
>
> > the mainline code?
> >
> > Also, I'm dependent on the .svn-workaround for Visual Studio it
> > appears, so then I have two branches to consider when building.
> >
> > As far as I'm concerned it's a major "bug" in the design of
>
> SVN. I am
>
> > once again missing something obvious such that there are major
> > use-cases where such a merge would break something?
> >
> > I can't see the problem with supporting proper date-time
>
> stamps on files.
>
> > Are there any plans to merge this with the mainline?
> >
> > Svante
>
> http://marc.theaimsgroup.com/?l=subversion-dev&m=112418966912502&w=2
>
> I've already discussed that several times ... the core
> developers seem not to be interested.
>
> But maybe if enough people complain ...
-------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Import and Commit and file modification times
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 18, 2005, at 2:04 AM, Svante Seleborg wrote:
> Anyone who can respond to the real issue? Will timestamp metadata
> preservation make to the 1.3 release?
I don't think anyone's working on it.
The reason the feature doesn't exist is because a formal design has
never been proposed or discussed. Ph. Marek was kind enough to code
up something "which works", but that branch has never been merged to
trunk. It won't be merged until someone picks up the lead on this
feature and leads the design discussion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Import and Commit and file modification times
Posted by Svante Seleborg <sv...@axantum.com>.
(snip)
> You were talking about the .svn vs. _svn issue, that's what I
> responded to.
Oh, well, that explains things.
But as the subject implies, and the text in the orignal message clearly
states, that issue was the lesser of the two, just an aside. That's merely a
hard-to-understand-the-reason-for annoyance. I can live with it.
Still hoping for "proper" timestamp handling in 1.3. I cannot use SVN before
then.
Anyone who can respond to the real issue? Will timestamp metadata
preservation make to the 1.3 release?
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Import and Commit and file modification times
Posted by Branko Čibej <br...@xbc.nu>.
Svante Seleborg wrote:
>Thank you for the answer!
>
>(snip)
>
>
>>>But, since I happen to do .NET-development as well I first
>>>
>>>
>>of all need
>>
>>
>>>a special build to work around some obscure Visual Studio-bug with
>>>directory names beginning with "dot". This is sort of off-topic, but
>>>why on earth can't this be made the supported behavior on
>>>
>>>
>>the Windows
>>
>>
>>>platform, instead of making a custom explicitly non-supported build?
>>>
>>>
>>>
>>1) Why do you think we should fix Microsoft's bugs in SVN?
>>
>>
>Because many, many developers use Windows and CVS, and you want them to use
>SVN instead.
>
>
>>2) We're already working on this, it'll probably be in 1.3.
>>
>>
>Assuming "this" is the timestamp issue, that's great news!
>
>
You were talking about the .svn vs. _svn issue, that's what I responded to.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Import and Commit and file modification times
Posted by Svante Seleborg <sv...@axantum.com>.
Thank you for the answer!
(snip)
> >But, since I happen to do .NET-development as well I first
> of all need
> >a special build to work around some obscure Visual Studio-bug with
> >directory names beginning with "dot". This is sort of off-topic, but
> >why on earth can't this be made the supported behavior on
> the Windows
> >platform, instead of making a custom explicitly non-supported build?
> >
> 1) Why do you think we should fix Microsoft's bugs in SVN?
Because many, many developers use Windows and CVS, and you want them to use
SVN instead.
> 2) We're already working on this, it'll probably be in 1.3.
Assuming "this" is the timestamp issue, that's great news!
It's obviously kind of late to affect the outcome, but it would be really
nice if it made it into 1.3. According to the project status page it's
medium priority (3) and only "considered" for inclusion into 1.3.
I'll keep my fingers crossed, hope for the best, and wait for that for the
final migration to SVN.
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Import and Commit and file modification times
Posted by Branko Čibej <br...@xbc.nu>.
Svante Seleborg wrote:
>But, since I happen to do .NET-development as well I first of all need a
>special build to work around some obscure Visual Studio-bug with directory
>names beginning with "dot". This is sort of off-topic, but why on earth
>can't this be made the supported behavior on the Windows platform, instead
>of making a custom explicitly non-supported build?
>
1) Why do you think we should fix Microsoft's bugs in SVN?
2) We're already working on this, it'll probably be in 1.3.
As to why those builda are not supported: search the mailing list
archives, there were lots of discussions about that.
> Just because Unix has a
>long tradition of hiding directories starting with "dot" from casual view
>(because of missing file-system features),
>
Ha ha ha. Missing filesystem features indeed. When the fastest Windows
FS is twice as slow as any normal Unix FS, I can damn well live without
hidden-file flags on Unix.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Import and Commit and file modification times
Posted by Svante Seleborg <sv...@axantum.com>.
To the developers of Subversion,
I'm an open source developer (axpipe and axcrypt.sf.net), wanting to migrate
from CVS.
Subversion has many advantages, and I'd like to thank you for all your
efforts and an excellent result made available to the community.
But, since I happen to do .NET-development as well I first of all need a
special build to work around some obscure Visual Studio-bug with directory
names beginning with "dot". This is sort of off-topic, but why on earth
can't this be made the supported behavior on the Windows platform, instead
of making a custom explicitly non-supported build? Just because Unix has a
long tradition of hiding directories starting with "dot" from casual view
(because of missing file-system features), why use that kludge on the
Windows platform which since the beginning of time has had that feature in
the file system in the form of the "hidden" file attribute??? Multi-platform
support includes adapting to the local system behavior. When in Rome, do as
the Romans do.
Now to the real issue.... ;-)
Most projects do not begin with a clean slate and an installation of
Subversion. Most of us have code that we want to start with, and import.
Part of that code consists of various meta information, such as the file
name and last time of modification (NOT last time of commit! - That is a
different story, and is about migration from one repository to another).
Unfortunately these two issues adds up to Subversion currently not being
such a totally compelling replacement for CVS as I'd like, and for many with
me apparently.
On a very fundamental basis, I think it's important to think about what a
repository and source code control system does, and should do. In my mind -
the operation sequence: Import - Checkout/Export should be a no-operation as
far as the sources involved are concerned - i.e. they should not be
modified!!!
If you don't change anything, you should always be able to take out exactly
what you put into the repository. Otherwise you loose information. Can
anyone even consider a backup-program which does not restore the filenames
and timestamps correctly, but instead substitutes the time of backup when
you restore? Granted, Subversion is not a backup program, but the
expectation is similar in this regard for most users.
I'm the one who should be modifying the sources - NOT the repository (unless
I specifically ask for it, for example by insertion of keyword
replacements). There's meta information in the repository, but that's a
different thing. It's kept by the repository, and should I ever want to
change repository that's a migration issue.
There are two fundamental pieces of meta information attached to source code
files, which are external to the actual text of the files and unrelated to
any repository:
1 - The file name
2 - The file modification timestamps
For some reason, Subversion is designed such that the file name should
remain unmodified by the repository, but the file modification timestamps
should not. Why?
Both the file name AND the timestamps are used by external processes to
control builds, affect the output, and should remain unchanged by the
repository!
Both the file name AND the timestamps are used by humans to understand the
structure and history of the sources.
It's no science fiction to imagine a scenario where the file names and the
timestamps are used both to control the actual build, and even are included
in the final output. Specifically - Subversion breaks my build system for
AxCrypt.
Subversion states: "The goal of the Subversion project is to build a version
control system that is a compelling replacement for CVS in the open source
community".
There are apparently quite a few open source developers who would prefer
that ALL of the external meta information of a file is maintained unmodified
by the repository, and apparently few who argue against it.
I'd like to make a strong case for Subversion to re-consider the current
stance on this issue.
There's even code available to implement it - or at least part of it, from
Philipp Marek. If that code, for whatever reason, is not acceptable to bring
into the mainline I'd be pleased to participate in the design and
development of this feature myself.
To summarize:
- There is obviously a significant part of the open source community
using/wanting to use Subversion who are negatively affected by two major
design decisions in Subversion - The .svn thing, and the timestamp issue.
- Subversion has as it's mission goal to attract users. This must reasonably
imply that users opinions are what counts! (I didn't write the mission goal
- but since it states what it does, a logical conclusion is that the voice
of the users is important.)
- Those same users even offer their time and help in good open source
community spirit.
- Let's just get this done with, so Subversion can become an even more
compelling replacement for CVS for more users, in more environments!
Best regards,
Svante
(snip - The apparently frequent question about original timestamp
preservation)
> > I'm not that keen on running off a special branch, it raises the
> > barrier of entry pretty much - isn't there any plan to
> merge this into
> > the mainline code?
> >
> > Also, I'm dependent on the .svn-workaround for Visual Studio it
> > appears, so then I have two branches to consider when building.
> >
> > As far as I'm concerned it's a major "bug" in the design of
> SVN. I am
> > once again missing something obvious such that there are major
> > use-cases where such a merge would break something?
> >
> > I can't see the problem with supporting proper date-time
> stamps on files.
> >
> > Are there any plans to merge this with the mainline?
> >
> > Svante
> http://marc.theaimsgroup.com/?l=subversion-dev&m=112418966912502&w=2
>
> I've already discussed that several times ... the core
> developers seem not to be interested.
>
> But maybe if enough people complain ...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org