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
Received on Wed Aug 17 12:29:18 2005