Just a general comment on this proposal
To reiterate the solution provided by Mike, I think this problem can be
easily solved by user methodology with no changes to fossil. If you have
generated or user edited files create and check in templates. Add the
appropriate targets to your make file t
On Mon, Jul 2, 2012 at 3:52 PM, Mike Meyer wrote:
> My solution has been to push things out to the build system. What gets
> stored in the repo is config.template. In this, the "values" for
>
Another option might, depending on the system, be to "include" a local
config file/make file/whatever. e
On Mon, 2 Jul 2012 08:08:18 -0400
Richard Hipp wrote:
> I am willing to *consider* some option that says "do not commit these
> files, even if they change, unless that are specifically named on the
> command-line". I think this would be easy to implement by messing
> with the is_selected()/if_se
If it happens I have some spare time, I'll look on the
{is/if}_selected and will report on any progress.
Cheers,
Jacek
2012/7/2 Stephan Beal :
> On Mon, Jul 2, 2012 at 3:09 PM, Jacek Cała wrote:
>>
>> Is there any difference except from being in the repo. I'd say,
>> "truly" ignored files a
On Mon, Jul 2, 2012 at 3:09 PM, Jacek Cała wrote:
> Is there any difference except from being in the repo. I'd say,
> "truly" ignored files are not in the repo at all, while "partially"
> ignored happen to be although the scm just ignores their local
> counterparts. Am I missing something?
>
Tha
On Mon, Jul 2, 2012 at 5:24 AM, Jacek Cała wrote:
> Hi All,
>
> I've got in my repo a small number of files that are changing but
> these changes are not meant to be send to the repo (are kind of
> user-specific). The files are needed in the repo but only in their
> initial or some specific ver
2012/7/2 Stephan Beal :
> On Mon, Jul 2, 2012 at 3:04 PM, Jacek Cała wrote:
>>
>> Couldn't it just be that when a file (a set of files '*.whatever') is
>> in the ignore-glob it behaves exactly like Richard suggested. From a
>> user perspective that would be simpler -- just one list which means
>>
On Mon, Jul 2, 2012 at 3:04 PM, Jacek Cała wrote:
> One more thought. Perhaps, there's no need for a separate ignore list
> but just a bit different semantics of the existing 'ignore-glob'.
>
In my experience, changing/extending semantics means lots of new room for
special cases and backwards co
One more thought. Perhaps, there's no need for a separate ignore list
but just a bit different semantics of the existing 'ignore-glob'.
Couldn't it just be that when a file (a set of files '*.whatever') is
in the ignore-glob it behaves exactly like Richard suggested. From a
user perspective that wo
2012/7/2 Stephan Beal :
> On Mon, Jul 2, 2012 at 2:49 PM, Jacek Cała wrote:
>>
>> would be enough. However, I can imagine that someone has a large repo
>> and needs to set no-autocommit to more than 10 files. Then maintaining
>> an 'ignore-glob'-like list may become a pain.
>
>
> fossil/sqlite has
On Mon, Jul 2, 2012 at 2:49 PM, Jacek Cała wrote:
> would be enough. However, I can imagine that someone has a large repo
> and needs to set no-autocommit to more than 10 files. Then maintaining
> an 'ignore-glob'-like list may become a pain.
>
fossil/sqlite has routines for globbing, so it woul
This is exactly how I would expect it to work. And I like the '--all'
option, too.
The only thing is if anything better than a list like 'ignore-glob'
can be proposed. In my case it's just a few files, so such a list
would be enough. However, I can imagine that someone has a large repo
and needs t
On Mon, Jul 2, 2012 at 7:56 AM, Stephan Beal wrote:
> On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal wrote:
>
>> i'm not personally convinced that an ignore list would completely solve
>> the problem (i think that just might lead to more confusion ("i changed the
>> file, why isn't it showing as ch
On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal wrote:
> i'm not personally convinced that an ignore list would completely solve
> the problem (i think that just might lead to more confusion ("i changed the
> file, why isn't it showing as changed?") and corresponding bug reports).
> But it might be
On Mon, Jul 2, 2012 at 1:19 PM, Jacek Cała wrote:
> The thing is that either I'll commit these file every time they change
> (which makes a bit of mess in the repo) or I need to do a selective
> commit which omits these files (which after a tens of commits become a
> bit annoying).
>
Coincidenta
Hi Stephan,
I think it is an scm-level problem, at least for me ;-)
The thing is that either I'll commit these file every time they change
(which makes a bit of mess in the repo) or I need to do a selective
commit which omits these files (which after a tens of commits become a
bit annoying).
C
Hi! No, there us no such mechanism in fossil. I sometimes have similar
problems with makefiles and config *files*, but i have never considered
that to be an scm-level problem (maybe it is?).
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
On Jul 2, 2012 11:24 AM,
Hi All,
I've got in my repo a small number of files that are changing but
these changes are not meant to be send to the repo (are kind of
user-specific). The files are needed in the repo but only in their
initial or some specific version. Is there any way to turn off change
tracking for some fil
18 matches
Mail list logo
