I did consider that possibility, but it would be just an annoyance,
considering you can't compile without the sln and csproj files.
Diego
On Fri, Aug 19, 2011 at 08:59, Stephen Bohlen <[email protected]> wrote:
> For even more fun, it could be done NOT as a comment, but just bare text,
> making the file completely uncompilable to anyone :)
>
>
> Steve Bohlen
> [email protected]
> http://blog.unhandled-exceptions.com
> http://twitter.com/sbohlen
>
>
> On Fri, Aug 19, 2011 at 7:55 AM, Diego Mijelshon
> <[email protected]>wrote:
>
>> One more twist on the old repo: a comment line could be added at the top
>> of every file too.
>> Something along the lines of:
>>
>> //YOU ARE SEEING AN OUTDATED VERSION OF THIS FILE
>> //The new NHibernate repository can be found at
>> https://github.com/nhibernate/nhibernate-core
>>
>> Diego
>>
>>
>>
>> On Fri, Aug 19, 2011 at 08:30, Stephen Bohlen <[email protected]> wrote:
>>
>>> re: nhforge, there already are links ("Download NH3.2.0", "Getting
>>> Started", "Find answers in our forums", etc.) that handle most of the
>>> user-oriented actions so I think we're (perhaps) just talking about adding a
>>> "get the source" link or similar to the main section of the homepage there.
>>> If anyone wants to replace the text-based links with more obvious 'button
>>> graphics' or some-such, I'd certainly be in favor of that effort (to
>>> increase the prominence of these links for newcomers to nhforge). I can see
>>> the argument that displaying them as text links doesn't result in their
>>> being featured prominently enough to get a visitor's attention quickly.
>>>
>>> I would (perhaps) suggest also that we consider doing something about the
>>> "Downloads" menu item b/c its both full of mostly outdated content *and*
>>> misleading in that it makes one think that's where I'd go to download NH.
>>> Perhaps we change the menu item to "Community-posted downloads" or
>>> something...? it looks like the community has begun to post downloads here
>>> that are really available elsewhere (SF, etc.), probably because navigating
>>> SF to find the downloads is too annoying/difficult.
>>>
>>> Since the page pointed to by the "Downloads" menu (
>>> http://nhforge.org/media/) seems to mostly contain bins for things like
>>> NH Spatial, NHV, Castle AR, FluentNH, etc., it seems clear to me that having
>>> a central source for authoritative links to the latest bins/packages for the
>>> broader NH 'universe' of related projects would be valuable.
>>>
>>> To accommodate this need, I would suggest that we consider changing the
>>> link on the homepage that reads "Download NH3.2.0" from linking directly to
>>> the NH GA bins to instead redirecting to some pre-authored page on nhforge
>>> that contains a more comprehensive collection of download links (latest NH
>>> GA, each of the latest NHContrib bin packages, FluentNH, uNHAddins, ConfORM,
>>> whatever) all organized and categorized/labeled to make it easy for someone
>>> to find whatever NH-related download they are seeking. To make it simple to
>>> permalink to this one page, I propose that this page url be just
>>> http://nhforge.org/downloads/ or something equally simple to
>>> remember/share with others. Then we need to just maintain the currency of
>>> the links on this one page as downloads are updated, etc. over time (the
>>> homepage need not change).
>>>
>>> This -- the redesign of elements of nhforge to increase clarity of
>>> navigation/cohesiveness of user experience -- is certainly a useful
>>> discussion, but IMO its somewhat off-topic for the more narrow pressing
>>> discussion of VCS choice.
>>>
>>> Getting back to that, re: the disposition of the SVN repo my vote would
>>> be to use the approach suggested earlier of adding the
>>> OBSOLETE_DO_NOT_USE_THIS_REPO.txt file (or sim.) message to every folder and
>>> deleting the .csproj, .sln, NANT, binary references, etc. content (e.g.
>>> pretty much everything but the .cs files) so that existing links retain
>>> their proper function but anyone checking out from the repo is left with an
>>> unbuildable tree.
>>>
>>> This will permit existing permalinks (well, as we're discussing, clearly
>>> NOT perma- at all <g>) to remain navigable/intact for blog posts, etc. while
>>> providing a non-ignorable flag-in-your-face about where the authoritative
>>> repo has been relocated.
>>>
>>>
>>> Steve Bohlen
>>> [email protected]
>>> http://blog.unhandled-exceptions.com
>>> http://twitter.com/sbohlen
>>>
>>>
>>>
>>> On Thu, Aug 18, 2011 at 8:53 PM, Patrick Earl <[email protected]> wrote:
>>>
>>>> Given that github doesn't have download metrics and NHForge doesn't
>>>> have bandwidth, I think it makes sense to leave the files on SF.net.
>>>> I also agree strongly about providing obvious download links on
>>>> nhforge.org. As far as I'm concerned, SF.net should be nearly
>>>> invisible, since it's hard to navigate, ugly, and not really providing
>>>> much in the way of services to us anyways.
>>>>
>>>> Regarding the repository, it sounds like various people have linked to
>>>> the old repository. I think it would be worth considering simply
>>>> turning off the SVN service. There would be no question of the
>>>> authoritative source if the SVN repository was simply not present.
>>>> This would prevent stale links to old versions of the source.
>>>> Granted, if the links already specify the revision, then this isn't so
>>>> problematic. That said, is there really that much in the way of
>>>> linkage that's worth preserving? Losing a number of links is in my
>>>> mind less important than being unambiguous about the home. Many times
>>>> in the past I've been looking for the project repo and I have come
>>>> across a stale one first. On the same train of thought, we should
>>>> have big obvious links to our major web sections from the main page of
>>>> the nhforge site... downloads, reporting issues (not just jira, but a
>>>> page that tells HOW to do it), source control, and the rest of the
>>>> nhforge content.
>>>>
>>>> Patrick Earl
>>>>
>>>> On Thu, Aug 18, 2011 at 6:20 PM, Stephen Bohlen <[email protected]>
>>>> wrote:
>>>> > Yeah, thought not :)
>>>> >
>>>> > Given the constraints we have, I think the answer is probably "leave
>>>> the
>>>> > downloads where they are on SF" for now. Its already in place, works
>>>> fine,
>>>> > and its location is common knowledge among present adopters.
>>>> >
>>>> > We might want to more prominently feature the links on nhforge to the
>>>> > downloads on SF, but otherwise I'd probably argue for leaving all else
>>>> > as-is.
>>>> >
>>>> > Choosing a different VCS can probably be done without really needing
>>>> to make
>>>> > changes to any other aspects (JIRA, downloads, whatever) of the
>>>> > infrastructure.
>>>> >
>>>> > There's probably a separate long-term conversation about centralizing
>>>> > everything under one roof/hoster/system/domain but its sounding to me
>>>> like
>>>> > this needs to be a different decision process not on the critical path
>>>> for
>>>> > our resolving the VCS issue amongst ourselves.
>>>> >
>>>> > Does this seem reasonable?
>>>> >
>>>> > -Steve B.
>>>> > ________________________________
>>>> > From: John Davidson <[email protected]>
>>>> > Sender: [email protected]
>>>> > Date: Thu, 18 Aug 2011 19:58:09 -0400
>>>> > To: <[email protected]>
>>>> > ReplyTo: [email protected]
>>>> > Subject: Re: [nhibernate-development] VCS Vote
>>>> > NHForge definitely does not have the bandwidth capacity to manage the
>>>> > download volume.
>>>> > John Davidson
>>>> >
>>>> > On Thu, Aug 18, 2011 at 7:27 PM, Stephen Bohlen <[email protected]>
>>>> wrote:
>>>> >>
>>>> >> I fear that the issue with nhforge-hosted downloads is both bandwidth
>>>> and
>>>> >> metrics-capture (both of which SF does handle just fine for the most
>>>> part).
>>>> >> Is there an (easy) way to capture metrics from nhforge?
>>>> >>
>>>> >> People are used to going to SF for downloads and prominent links to
>>>> SF
>>>> >> download pages from nhforge for new adopters starting at nhforge seem
>>>> like
>>>> >> an ok compromise to me.
>>>> >>
>>>> >> -Steve B.
>>>> >>
>>>> >> ________________________________
>>>> >> From: Julian Maughan <[email protected]>
>>>> >> Sender: [email protected]
>>>> >> Date: Fri, 19 Aug 2011 07:18:25 +0800
>>>> >> To: <[email protected]>
>>>> >> ReplyTo: [email protected]
>>>> >> Subject: Re: [nhibernate-development] VCS Vote
>>>> >>
>>>> >> +1 for consolidation then :)
>>>> >>
>>>> >> That tends to suggest to me that hosting downloads on SF would be a
>>>> bad
>>>> >> idea. If release downloads are to be regarded as a front-of-shop
>>>> concern
>>>> >> (which I think they should), can't we host releases on the NHForge
>>>> server?
>>>> >> The user then doesn't have to be redirected to an unrelated,
>>>> ad-sponsored
>>>> >> page on SF (at the back-of-shop, to continue the analogy)
>>>> >>
>>>> >> On 19/08/2011 6:56 AM, "Stephen Bohlen" <[email protected]> wrote:
>>>> >> > Agreed. I'd posited early on that along w a move to *some* VCS
>>>> hosting
>>>> >> > provider we needed to consolidate the all else around NHForge so
>>>> that all
>>>> >> > existing deprecated resources could simply point to NHForge as a
>>>> hub from
>>>> >> > which links to all else (JIRA, downloads, whatever) could emanate.
>>>> >> >
>>>> >> > With JIRA remaining hosted by Atlassian, source somewhere (yet to
>>>> be
>>>> >> > decided), what other than downloads still needs a 'home' at this
>>>> point?
>>>> >> >
>>>> >> > -Steve B.
>>>> >> > -----Original Message-----
>>>> >> > From: Julian Maughan <[email protected]>
>>>> >> > Sender: [email protected]
>>>> >> > Date: Fri, 19 Aug 2011 06:48:15
>>>> >> > To: <[email protected]>
>>>> >> > Reply-To: [email protected]
>>>> >> > Subject: Re: [nhibernate-development] VCS Vote
>>>> >> >
>>>> >> > I just think if the project infrastructure is too fragmented, it
>>>> will
>>>> >> > become
>>>> >> > confusing. I think we can divide the infrastructure into two
>>>> categories:
>>>> >> > front-of-shop and back-of-shop. I think it is important there is
>>>> one
>>>> >> > place
>>>> >> > users go for downloads, doco, etc. (NHForge). The back-of-shop
>>>> stuff -
>>>> >> > eg
>>>> >> > (VCS, bug-tracker) - it doesn't matter so much. That is the reason
>>>> I
>>>> >> > raised
>>>> >> > the question about download hosting.
>>>> >> > On 19/08/2011 6:37 AM, "Stephen Bohlen" <[email protected]> wrote:
>>>> >> >> Yeah, some time ago (early on in this last attempt at this) I
>>>> pointed
>>>> >> >> out
>>>> >> > that there are indeed two distinct categories in which we're trying
>>>> to
>>>> >> > make
>>>> >> > a decision: VCS specifically and project infrastructure more
>>>> broadly
>>>> >> > (issue
>>>> >> > tracking, announcements, etc).
>>>> >> >>
>>>> >> >> Even if we go to github for VCS, I'm not sure this precludes our
>>>> >> >> retaining
>>>> >> > sourceforge + nhforge in the other roles (e.g., as we were already
>>>> >> > discussing earlier today re: central hub for downloads, etc ).
>>>> >> >>
>>>> >> >> Couldn't a move to github for VCS leave all else exactly as-is and
>>>> be a
>>>> >> > (relatively) non-invasive change (wondering....)?
>>>> >> >>
>>>> >> >> -Steve B.
>>>> >> >> -----Original Message-----
>>>> >> >> From: Julian Maughan <[email protected]>
>>>> >> >> Sender: [email protected]
>>>> >> >> Date: Fri, 19 Aug 2011 06:24:45
>>>> >> >> To: <[email protected]>
>>>> >> >> Reply-To: [email protected]
>>>> >> >> Subject: Re: [nhibernate-development] VCS Vote
>>>> >> >>
>>>> >> >> +1
>>>> >> >>
>>>> >> >> I don't have a problem with git or using GitHub as a source code
>>>> host.
>>>> >> >> However, GitHub doesn't seem as good as Google Code or CodePlex in
>>>> >> > offering
>>>> >> >> a project 'home'. Larger projects like NServiceBus, that use
>>>> GitHub for
>>>> >> >> their source, often have a strong alternative web presence with
>>>> their
>>>> >> >> website. If we use GitHub, I believe NHForge will need to be
>>>> improved
>>>> >> >> to
>>>> >> >> become a better project home. Do we have the resources for this
>>>> >> > improvement?
>>>> >> >> Maybe not.
>>>> >> >> On 19/08/2011 3:28 AM, "Richard Brown" <[email protected]>
>>>> wrote:
>>>> >> >>> Oops, sorry. I should have read more carefully.
>>>> >> >>> On 18 Aug 2011 20:25, "Fabio Maulo" <[email protected]>
>>>> wrote:
>>>> >> >>>> The meaning is:
>>>> >> >>>> -1 = Do not use the github repository, find another alternative.
>>>> >> >>>>
>>>> >> >>>> On Thu, Aug 18, 2011 at 3:23 PM, Richard Brown
>>>> >> >>>> <[email protected]
>>>> >> >>>>wrote:
>>>> >> >>>>
>>>> >> >>>>> Is that -1 for github? Or -1 for this specific branch?
>>>> >> >>>>>
>>>> >> >>>>> (just checking there isn't something wrong with the import I
>>>> wasn't
>>>> >> >> aware
>>>> >> >>>>> of.)
>>>> >> >>>>> On 18 Aug 2011 19:11, "Fabio Maulo" <[email protected]>
>>>> wrote:
>>>> >> >>>>> > -1
>>>> >> >>>>> >
>>>> >> >>>>> > On Thu, Aug 18, 2011 at 2:43 PM, Patrick Earl <
>>>> [email protected]>
>>>> >> >> wrote:
>>>> >> >>>>> >
>>>> >> >>>>> >> So we need to ensure there has been a clear decision on the
>>>> >> >>>>> >> source
>>>> >> >>>>> >> control matter. Committers should indicate one of the
>>>> following
>>>> >> >>>>> >> options.
>>>> >> >>>>> >>
>>>> >> >>>>> >> +1 = Use the github repository.
>>>> >> >>>>> >> -1 = Do not use the github repository, find another
>>>> alternative.
>>>> >> >>>>> >>
>>>> >> >>>>> >> Please respond on this thread with your vote.
>>>> >> >>>>> >>
>>>> >> >>>>> >> Patrick Earl
>>>> >> >>>>> >>
>>>> >> >>>>> >
>>>> >> >>>>> >
>>>> >> >>>>> >
>>>> >> >>>>> > --
>>>> >> >>>>> > Fabio Maulo
>>>> >> >>>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> --
>>>> >> >>>> Fabio Maulo
>>>> >> >>
>>>> >> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>
