On Wed, Mar 12, 2008 at 6:23 AM, Andy Levy <andy.levy_at_gmail.com> wrote:
> On Wed, Mar 12, 2008 at 1:29 AM, Mad Scientist
> <madscientist343_at_gmail.com> wrote:
> > Hi, I am looking to submit a feature request for unversioned files
> > stored in the repository along with normal versioned files. This could
> > be beneficial for files such as project licenses which apply to all
> > revisions
>
> Why would these need to be unversioned but in the repository? Put them
> in normally, and if they never change, how is it different from
> keeping them in the repo, unversioned?
The benefit would be when the files do need to be changed and applied to
previous revisions ( eg a license that covers all files in the repository )
you are able to change them on every revision( from the view of a working
copy ) instead of just changing the latest revision. As a note I was
thinking for the repository to store the files not by updating past
revisions but by having either a special revision number, -1 for instance,
or saved in another form as an overlay to the checked out revision.
>
>
> > or the latest generated files for people who do not want or
> > are unable to compile/build the files themselves.
>
> Have your build manager put them into a "release" tag which no one
> else is allowed to commit to, or place the items on a fileserver.
>
> > It keeps could also
> > keep the generated files in an easy to remove format when they become
> > out dated or space becomes an issue.
>
> This would require a very large change to Subversion - basically,
> you're asking for "svn obliterate" here, which I think is under
> consideration but involves a very large amount of work.
I was thinking this could be more of a side effect of a collision between a
file in the repository and overlay where the revisioned item gets
overwritten in the working copy. Though as you allude to below it could get
messy with at least one problem being important files unintentionally
covered up by an unversioned file.
>
> > I was thinking maybe these files
> > could be stored internally ( just a guess/suggestion ) at revision 0 or
> > -1 and override any versioned files.( could allow misplaced files to be
> > 'removed' as a quick patch until the repository is fixed, confidential
> > data on a public repository for instance )
>
> This sounds like it could get real messy and provide the potential for
> work to be lost.
As another option could be adjusting svn:external to work with http/ftp
links to external files. Which could offer much of the functionality of
unversioned files in the repository while being simpler to implement but
could have its own problems if a repository is moved or the site goes
down/moved.
Received on 2008-03-12 16:54:22 CET